Found during #318's ship review, in the settings page's sibling action.
What happens
removeSupporterKey (src/routes/admin/settings/+page.svelte:1151) calls await update({ reset: false }) in its enhance handler. That reruns the page load, which fires the resync $effect that reassigns every Site-tab field from data.settings. Any unsaved edit in those fields is silently reverted.
The settings page renders every tab's sections into one panel and hides the inactive ones with CSS, so unsaved Site-tab edits are still in the DOM while the operator is on the Account tab. Type a new site name, switch to Account, remove a supporter key, and the typed name is gone with no warning.
Why it wasn't fixed in #318
The identical bug on the Regenerate button was fixed there (see #318, commit 6df0ab7): the action returns the value the page needs and the handler updates just that field instead of reloading. Sparky chose to fix the new button rather than grow that change into a sweep of the page.
The fix, already proven once
Follow the pattern from regenerateFeedKey: have the action return what the display needs, hold it in local state preferred over the loaded value, drop the update() call, and route non-success results through applyAction so failures and redirects are not swallowed. That last part matters and is easy to miss: dropping update() also drops the applyAction it runs internally.
Worth checking the page's other actions for the same shape while you are in there.
Test
The Regenerate equivalent is pinned in src/routes/admin/settings/server.test.ts ("shows the new address without reloading the page data"). Note that pin searches raw source and runs against a comment-stripped copy, for the reason documented inline.
Found during #318's ship review, in the settings page's sibling action.
What happens
removeSupporterKey(src/routes/admin/settings/+page.svelte:1151) callsawait update({ reset: false })in its enhance handler. That reruns the page load, which fires the resync$effectthat reassigns every Site-tab field fromdata.settings. Any unsaved edit in those fields is silently reverted.The settings page renders every tab's sections into one panel and hides the inactive ones with CSS, so unsaved Site-tab edits are still in the DOM while the operator is on the Account tab. Type a new site name, switch to Account, remove a supporter key, and the typed name is gone with no warning.
Why it wasn't fixed in #318
The identical bug on the Regenerate button was fixed there (see #318, commit
6df0ab7): the action returns the value the page needs and the handler updates just that field instead of reloading. Sparky chose to fix the new button rather than grow that change into a sweep of the page.The fix, already proven once
Follow the pattern from
regenerateFeedKey: have the action return what the display needs, hold it in local state preferred over the loaded value, drop theupdate()call, and route non-success results throughapplyActionso failures and redirects are not swallowed. That last part matters and is easy to miss: droppingupdate()also drops theapplyActionit runs internally.Worth checking the page's other actions for the same shape while you are in there.
Test
The Regenerate equivalent is pinned in
src/routes/admin/settings/server.test.ts("shows the new address without reloading the page data"). Note that pin searches raw source and runs against a comment-stripped copy, for the reason documented inline.