pinEffect: a rename inside a collapsed branch gets only a tag-keyed entry #1503

New issue

Open

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

kiara commented

2026-08-20 13:54:54 +02:00

Owner

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

core/lib/renames-for-source.nix emits every rename it recovers at the path the option sits at, so a rename inside a deployment-method branch comes out keyed on deployment-method.<tag>.<...>. Under pinEffect the served schema drops deployment-method and lifts the pinned branch to the root, and pinLift (deployment-method.<tag>.* -> *) carries the stored value across. That works for a rename of a whole branch setting, but not for a rename inside one that is not an operator scalar: the tag-keyed entry does not match a root-shaped configuration stored after the pin, and the lift does not match it either, because the lift is a single wildcard step and the rename sits below it.

That applications, domain and email are covered today is an accident of their being declared twice -- once on the branch and once at the root -- not something the emission guarantees.

Fix: have pinEffect re-emit each deployment-method.<pin>.<...> entry a second time with the prefix stripped, so a value-space move applies to both shapes.

Vacuous for the current table, which is [ ] -- there is no rename to be wrong about yet. It becomes real with the first entry in an application's settings-renames.json, or the first mkRenamedOptionModule declared inside a deployment method.

Follow-up split out of the work on #629. `core/lib/renames-for-source.nix` emits every rename it recovers at the path the option sits at, so a rename inside a `deployment-method` branch comes out keyed on `deployment-method.<tag>.<...>`. Under `pinEffect` the served schema drops `deployment-method` and lifts the pinned branch to the root, and `pinLift` (`deployment-method.<tag>.* -> *`) carries the stored value across. That works for a rename of a whole branch setting, but not for a rename *inside* one that is not an operator scalar: the tag-keyed entry does not match a root-shaped configuration stored after the pin, and the lift does not match it either, because the lift is a single wildcard step and the rename sits below it. That `applications`, `domain` and `email` are covered today is an accident of their being declared twice -- once on the branch and once at the root -- not something the emission guarantees. Fix: have `pinEffect` re-emit each `deployment-method.<pin>.<...>` entry a second time with the prefix stripped, so a value-space move applies to both shapes. Vacuous for the current table, which is `[ ]` -- there is no rename to be wrong about yet. It becomes real with the first entry in an application's `settings-renames.json`, or the first `mkRenamedOptionModule` declared inside a deployment method.

~~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 referenced this issue from a pull request that will close it,

2026-08-20 22:24:16 +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