Any admin Save silently resets peeringEnabled (and other non-form settings) — saveSettings PUTs a partial object #306
Labels
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Cordy/Cairn#306
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Dogfood finding (2026-08-21, Nikola): "global peering on the Bao instance always turns off upon redeployment and the files instance does not."
Diagnosis: not the redeploy.
PUT /api/v1/settingshas documented REPLACE semantics; the frontendsaveSettings()builds its body by hand from the admin form fields only —peeringEnabled,peeringExpandGroups,peeringMaxFileBytes,peeringBaseUrlare absent, decode as zero values, and get persisted as such. So every admin Save (basic/sharing/storage/retention/trash/audit) turns peering off. Redeploys correlate because each release's dogfood checklist includes an admin Save on bao; enc kept its toggle only because nothing was saved there since peering was enabled. The peering panel's own toggle already does it right (Object.assign({}, serverSettings, {...})) — #134's pattern never reached the oldersaveSettings.Persistence itself is healthy: both instances run state-in-backend (#153), settings write through
statestoreencrypted to the bucket, and the boot gate is a live closure onsettingsStore.Get().PeeringEnabled.Fix:
saveSettingsmerges its form fields overserverSettings(JSON.stringify(Object.assign({}, serverSettings, {...}))), preserving every field the form doesn't own — including any future settings fields, which makes this a one-time fix for the whole class.Known residual (accepted): two admins saving concurrently can still lose each other's changes (last-writer-wins on the full object) — inherent to #52's replace semantics, fine for the beta.
Hotfix shipped as v0.6.62 (PR #307), live on both dogfoods.
saveSettingsnow sendsObject.assign({}, serverSettings, { …form fields… })— the same merge pattern the peering toggle already used — so any field the admin forms don't own (peering enable, group expansion, transfer cap, base URL, and whatever we add later) survives every Save.Dogfood checklist (bao is the good testbed):
One note from the diagnosis worth keeping in mind: the resets you saw "on redeployment" were actually caused by the admin Saves in each release's checklist — the redeploy itself never touched settings, and state-in-backend (#153) was persisting everything it was given correctly on both instances.
fixed