Fold data-shape review into the forking plan - #507
Merged
Conversation
A review pass focused on data shape at each deployment and loss/corruption risk. All claims verified against the codebase; the plan gains the three M1 mechanics it had left implicit and a design-level data-safety section. M1: the position backfill must offset from the per-thread max rather than numbering from 1 - the statement re-applies on every deploy as a NULL sweeper, and a NULL straggler from the window between backfill and trigger creation would otherwise collide with the unique index and block every subsequent deploy. The trigger assigns only when the caller provided no position, so recovery's fractional midpoints pass through (the insert helper's created_at override becomes a position parameter). The move-to-tail path is an UPDATE the trigger never sees, so it sets position explicitly via read-then-write (safe under the per-thread response claim) or a small RPC. The old-frontend recovery-row divergence during the deploy window is documented as accepted: narrow, rare, self-healing, mis-ordered not lost. Design: new section stating the mixed-version window constraint (schema must serve old and new frontends), the per-milestone rollback guarantees (all loss-free; M4+ reverts disable entry points but keep the resolver and hidden filters), and the scope statement that the backfill is the only operation touching existing rows.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Doc-only amendment folding a data-shape / loss-risk review round into the forking plan. M1 gains its three implicit mechanics made explicit: the position backfill must offset from the per-thread max (the statement re-applies on every deploy as a NULL sweeper; a non-offset version collides with the unique index on a straggler and blocks every subsequent deploy), the trigger yields to caller-provided positions (recovery's fractional midpoints; the insert helper's created_at override becomes a position parameter), and the move-to-tail UPDATE sets position explicitly (trigger never fires; read-then-write is safe under the per-thread response claim). The accepted deploy-window recovery-row divergence is documented. New design section: the mixed-version window constraint (schema must serve old and new frontends simultaneously), per-milestone rollback guarantees (all loss-free; M4+ reverts disable entry points but keep the resolver and hidden filters), and the scope statement that the backfill is the only operation touching existing rows.
Generated by Claude Code