- Shipped
- August 22, 2026 at 10:05 PM UTC
- Author
- Kamo
- Commit
- 13381cc
Where a document has both kinds, the CLASSIC row survives — it is the one that may hold edited bytes — the design is repointed onto it, and the FORM_FILLABLE row is deleted. Losing either side would be losing member work: the bytes are edits made in LibreOffice, the design is field placement done by hand. The unique index becomes one row per original rather than one per (original, kind), and is only built after the merge leaves no document holding two. modified_kind is deliberately left in the table. Dropping it would break any DocsService pod still running the previous image mid-rollout, which names the column in every Img SELECT; it can go once the fleet has turned over. The earlier runner no longer creates the old per-kind unique index, so the two migrations do not spend every run fighting over it. Applied to prod ahead of this push: 8 modified rows, 4 carrying designs, 2 with diverged bytes, none doubled, nothing lost.