a stored value under a key upstream removed has nowhere to go #1505

New issue

Open

opened 2026-08-20 13:55:30 +02:00 by kiara · 0 comments

kiara commented

2026-08-20 13:55:30 +02:00

Owner

Follow-up split out of the work on #629.

A rename is a move: { from, to }, and migrate_value deep-moves the stored value before validation. A removal is not. When a pinned upstream schema drops a key an application offers, the selection check in core/lib/option-selection.nix fails the build with the name that is gone, and the answer is to delete that key from the applications operatorSettings-- there is noto` to carry a value to.

What then happens to an operator who already stored something under it: the value survives in Deployment.value / deployment.config, migration leaves it alone (correctly -- no entry names it), and validation rejects the whole configuration as invalid_configuration, because narrow seals every object it emits with additionalProperties: false. The message names a stray property, not the fact that upstream removed the setting.

Options, none chosen:

a third verb beside the rename table -- a declared removal, dropping the key on read and reporting it the way unmigrated reports a skipped rename;
leave the value in place and report it as a warning rather than a rejection;
nothing, and let the operator re-submit the form.

The boundary is documented as it stands in api/specification.md (Migration semantics) and core/docs/md/operator-config.md.

Follow-up split out of the work on #629. A rename is a move: `{ from, to }`, and `migrate_value` deep-moves the stored value before validation. A *removal* is not. When a pinned upstream schema drops a key an application offers, the selection check in `core/lib/option-selection.nix` fails the build with the name that is gone, and the answer is to delete that key from the application`s `operatorSettings` -- there is no `to` to carry a value to. What then happens to an operator who already stored something under it: the value survives in `Deployment.value` / `deployment.config`, migration leaves it alone (correctly -- no entry names it), and validation rejects the whole configuration as `invalid_configuration`, because `narrow` seals every object it emits with `additionalProperties: false`. The message names a stray property, not the fact that upstream removed the setting. Options, none chosen: - a third verb beside the rename table -- a declared removal, dropping the key on read and reporting it the way `unmigrated` reports a skipped rename; - leave the value in place and report it as a warning rather than a rejection; - nothing, and let the operator re-submit the form. The boundary is documented as it stands in `api/specification.md` (Migration semantics) and `core/docs/md/operator-config.md`.

kiara referenced this issue

2026-08-20 14:08:40 +02:00

core/lib: carry a stored configuration across renames no single pin declares #1506

kiara added a new dependency

2026-10-01 17:30:19 +02:00

#629 schema updates automated