mirror of
https://github.com/maziggy/bambuddy.git
synced 2026-09-30 11:12:35 +02:00
maziggy
43cb216ae9
While the Settings page was mounted it held its own copy of every setting and synced it from the server exactly once, on first load (:887-900). A debounced effect then diffed the live ['settings'] cache against that copy and PUT all 77 keys it manages on any difference, with no way to tell a user edit from a value that had changed on the server. Anything written server-side while the page sat open was silently reverted ~500ms later (#2716, reporter @jmoore-skild). No interaction was needed to trigger it. The query inherits a 60s staleTime and react-query's default refetchOnWindowFocus, and ~30 other observers share the key, so a window refocus or a refetch from any of them moved the cache and the page wrote its page-load snapshot back over all 77 keys -- showing "Settings saved" while doing it. The page now tracks the last server snapshot it reconciled with. A field still equal to that baseline has not been touched since, so a newer server value is adopted; a field the user has edited keeps their value and is saved over the top, so the newer of the two writes wins either way. Typing into a text field while a refetch lands stays safe, which is what the previous behaviour was protecting -- an in-progress edit is by definition different from the baseline. The baseline is seeded from the raw server row rather than from the copy the page patches a browser-detected external_url into, so that detection still reads as a local change and is still persisted. The payload builder and the comparison key lists are unchanged. The diff simply measures against the baseline instead of the live cache, so no field can silently stop saving. Removing the adoption step was verified to reintroduce the revert, and removing the post-save baseline advance to reintroduce a resend loop; both are covered by frontend tests asserting on the request bodies rather than on rendered values.