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.
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 immutablenameswaps 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
FIXMEtest inapps/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.