fix(store): migrate relation fields when their target collection is renamed (BUG-2873)

[xarmian]

models.FieldDef.Collection holds the target's slug, and it is the only pointer a relation field carries — there is no id beside it. UpdateCollection re-slugifies on rename and nothing migrated the definitions aimed at it, so every relation field pointing at a renamed collection was stranded: the picker filters on a slug that resolves to nothing and the field silently stops being fillable.

retargetRelationFieldsTx re-points them in the same transaction as the rename, for the reason the field-value migrations already run there — a failure must roll the rename back rather than commit collections pointing at a name that no longer exists.

Zero affected rows, deliberately

A census across every workspace on this instance found no relation fields anywhere, and no shipped template declares one. The feature has been unusable, which is what PLAN-2857 exists to change. So this repairs the rename path before the population exists, which is why there is no data migration — and the "zero live rows" property is what makes the change cheap to review. Three findings were split out rather than folded in to preserve it (below).

What it does that an obvious version does not

• Parses instead of string-replacing. A schema's JSON contains the old slug in places that must not move — a text field's default, a select's options, a label. Only collection on a relation field is a reference. Export's remapFieldIDs gets away with a blind replace because it substitutes UUIDs, which cannot collide with prose; a slug is a word. Pinned by a control test.
• Locks the rows it rewrites (FOR UPDATE, ordered by id, on Postgres). Otherwise a concurrent sibling schema update commits between the scan and the rewrite and gets clobbered by a stale copy.
• Advances each rewritten row's OCC token, without ever regressing it. collections.updated_at doubles as the concurrency token (BUG-2265): leaving it unchanged lets a client holding the pre-rename schema write it straight back; stamping the rename's value on a sibling that was updated later moves the token backwards. Each row takes max(current + 1ns, renameToken), computed in Go rather than by comparing timestamp text, which the surrounding comment warns is never safe.
• Preserves properties it does not understand, including large integers. Round-tripping through models.CollectionSchema drops unknown keys; decoding into interface{} turns numbers into float64, so 9007199254740993 came back changed. Raw decode with UseNumber.
• Refuses a schema with trailing content rather than truncating it — Decode ignores what follows the first value where Unmarshal refuses it.
• Includes the renamed collection itself (a relation may target itself) and runs after the caller's own schema write, so a simultaneous schema edit composes rather than being reverted.

The deadlock hazard, and why the existing comment does not cover it

The lock-order comment above this transaction is a Codex P1 fix ordering the workspace lock against one collection row lock, because until now nothing took more than one. This change writes sibling rows, so two concurrent renames of mutually-referencing collections take them in opposite orders.

Reproduced, not theorised: with the serialization removed the test fails in 1.4s with ERROR: deadlock detected (SQLSTATE 40P01) on Postgres. Renames now take the workspace lock — previously acquired only when len(input.Migrations) > 0 — before the row lock, closing it without inventing a second ordering rule to keep in sync with the first.

Raised in review by a teammate who read the function on being asked, and flagged that a reviewer would hit that comment and assume the question was settled. It was not.

Split out rather than folded in

Each has dependents that are not the relation feature, so none belongs in a change whose reviewability rests on affecting zero live rows:

• IDEA-2874 — the new slug is allocated outside the transaction (uniqueSlugExcluding(s.db, …) at :420, before s.db.Begin() at :503). Its dependents are every collection rename in every workspace. UNIQUE(workspace_id, slug) makes today's behaviour loud rather than lossy, so it can wait. (The read of the old slug is fixed here — see below.)
• BUG-2875 — a collection created during a rename escapes the scan's FOR UPDATE. Closing it means CreateCollection takes the workspace lock, changing every collection creation on the instance.
• IDEA-2876 — migrated siblings emit no collection_updated event, so an open page keeps the pre-rename schema until reload. Handler layer; the store publishes nothing.

The read of the old slug was in scope and is fixed: it came from the pre-transaction snapshot, so two tokenless concurrent renames both saw the original, and the loser migrated original → its own new slug while the relations already said the winner's — matching nothing. It is now re-read alongside the token under the row lock.

Three instruments that were not instruments

Every one found by mutation rather than by reading, and each would have shipped a false green:

1. The deadlock test passed against its own mutant in 0.44s. Two unsynchronised goroutines never collided. A start barrier plus 40 rounds turned it into evidence.
2. The pre-tx-slug mutant survived the first matrix, because nothing forced the interleaving. Pinned instead by an end-state invariant that holds under any interleaving — whatever slug the collection ends up with, every relation aimed at it points there — over 40 concurrent rounds. It fails at round 1 under the mutant.
3. The mutation harness itself reported two false survivors. It counted --- FAIL lines, so a mutant that fails to COMPILE reads as one that survived. Deleting the token guard leaves rowUpdatedAt/renameToken unused; deleting the trailing-content guard leaves io unused. Both died immediately once made to compile. Twice in one unit is a harness defect, not bad luck.

One dialect asymmetry the Postgres gate caught

TestRenameLeavesASchemaWithTrailingJunkUntouched failed on Postgres at the seed, not the assertion: invalid input syntax for type json (22P02). collections.schema is TEXT on SQLite and JSONB on Postgres, so the state that guard defends against cannot be stored there at all. The test skips on Postgres with the reason recorded. Reading which line failed is what separated "my test is not portable" from "the product is broken on PG".

Verification

• Pin written and run BEFORE the fix (team CONVE-29): 2 propagation tests failed, the control passed.
• gofmt clean, go vet ./... ok.
• Full go test ./... green on SQLite.
• Full internal/store green on Postgres — 502.2s, private container at 127.0.0.1:5473, never the shared 5445 a sibling seat may tear down. Run detached with a sentinel after the first attempt was killed at a turn boundary.
• Mutation matrix: 7 applied, 7 killed.