Repository navigation
immutable-paths: array reorder re-anchors source values to new indices #3103
Description
What
The overlay aligns array entries by index. If the user reorders an array with a per-element-immutable nested field, source values follow the new indices rather than identities. Same-length reorder of [A,B] to [B,A] with immutable name swaps the names back.
Why it matters
Reorder is allowed at the UI layer (the field is just disabled, not the whole array), so this surfaces as soon as a real CRD ships a per-element immutability rule.
Pinned
Current behaviour is pinned by the FIXME test in apps/console/src/lib/immutable-paths.test.ts ("FIXME: array reordering by the user with index-aligned overlay re-anchors source values to the new index"). Identity-based matching (e.g. by a stable id field, or by content of the immutable field itself) would be the fix.
A neighbour bug, fixed in cozystack-ui#6, was the same root cause but for SHRINK: deleting a non-trailing element re-anchored source[0].name onto the surviving entry. That path now bails with a console warning; reorder is the remaining case.
Activity
fix(console): bail on shrink for nested-immutable arrays, handle root…
myasnikovdaniil commentedon Aug 15, 2026
Closing as not reachable. Zero shipped immutable paths contain a
*segment, sooverlayWildcardis never reached with a non-last wildcard. The platform ships 16 immutable paths and all of them are scalar, none crossing an array. Reopen if a definition ever adds a wildcard mid-path.