logic/correctness

Settings Can Set But Never Unset

#84rare5 sightingsfirst seen September 2026

What goes wrong

A settings form or API only lets you assign a value to a field whose empty (NULL) state means 'inherit the deployment default'. Once any value has been written there is no operation to clear it, so the inherit state is unreachable without editing the database directly.

Example

A tenant sets a custom session timeout and later wants the platform default back — but the form has no 'reset' and the update endpoint ignores null, so only a database admin can restore it.

Not to be confused with

The field was deliberately edited; not an untouched form that saves the shown default as an override (Untouched default becomes a permanent override) and not a failed read that invents defaults (Failed read becomes destructive patch input).

Discovered by

@sks24git GitHub

Field notes · 2

@sks24git2026-11-04
A settings form greyed out the choices a stricter parent rule made useless, but those choices meant 'follow the parent'. Once the parent rule relaxed, the child stayed locked closed, and no one had chosen that.
Grey out only what can never apply. A value that inherits a parent rule is a choice, not a widening.
Test the state after the parent changes back.
@sks24git2026-09-10beat 3 review rounds
After the first save there was no way back to 'not set, the default decides'. The validator refuses an empty list, no delete route exists, and a sibling settings area ships a reset sentinel.
Every setting needs a road back to unset. Ship the reset with the first write path, not later.
Copy the sibling area's shape before inventing your own.