fix(provenance): clear the rows that went unknown after the first repair - #6982
Conversation
0005 is finished and will not run again — the runner records a name in script_migrations and never offers it back, which is the contract a run-once repair wants. But it cleared the backlog that existed at the instant it ran, and the writer that produced that backlog kept running until the fix in this branch. Nothing heals such a row in place, so each one goes on reporting on every later read; a few dozen of them account for thousands of log lines a week. A second entry rather than deleting the first's tracking row: the registry is append-only, and a repair that ran twice should say so twice. It shares 0005's walk rather than restating it — the parent-first lock ordering and the status re-check under that lock are subtleties worth having once — and is idempotent, so it costs one empty query if there is nothing left to repair.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
PR SummaryMedium Risk Overview Extracts the existing keyset walk into Reviewed by Cursor Bugbot for commit ddd3507. Configure here. |
Greptile SummaryThis PR adds a separately registered second pass of the unknown table-row provenance repair while reusing the original migration’s locking and status-recheck implementation.
Confidence Score: 5/5The PR appears safe to merge. No blocking failure remains.
|
| Filename | Overview |
|---|---|
| packages/db/script-migrations/0005_repair_unknown_table_row_provenance.ts | Extracts the existing repair walk into a reusable function without changing its page-processing behavior. |
| packages/db/script-migrations/0006_repair_unknown_table_row_provenance_second_pass.ts | Adds a distinct migration entry that invokes the shared repair for rows created after the first pass. |
| packages/db/script-migrations/index.ts | Registers the second-pass repair after the original migration. |
| packages/db/script-migrations/0005_repair_unknown_table_row_provenance.test.ts | Verifies that the second pass uses the shared lock-before-delete walk and has a distinct migration name. |
Reviews (3): Last reviewed commit: "chore(provenance): record the deploy ord..." | Re-trigger Greptile
|
@cursor review |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 28290e2. Configure here.
promote-images needs migrate, so a script migration runs while the previous image is still serving. A row an old instance creates between this walk and the end of the rollout sits behind the cursor, and the name is recorded on success, so it is never offered again. Widening the walk would not help — the exposure is the minutes after it returns, not the milliseconds during — so the requirement is to ship it in a release after the writer fix is already promoted, which the file now says.
|
@cursor review |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit ddd3507. Configure here.
Summary
0005cleared the backlog that existed at the instant it ran, and is finished — the runner records a name inscript_migrationsand never offers it back, which is the contract a run-once repair wants. But the writer that produced that backlog kept running until the fix in fix(provenance): stop requiring a projection of roots no model sees #6981, so rows wentunknownafter it.0005's tracking row — the registry is append-only, and a repair that ran twice should say so twice.0005's walk rather than restating it. The parent-first lock ordering (matchingmutateTableRowsWithSecretProvenance) and thestatusre-check under that lock are subtleties worth having once, not twice. Idempotent, so it costs one empty query when there is nothing left.Ordered deliberately after #6981: repairing while the writer still creates unknowns only refills the backlog.
Type of Change
Testing
Tested manually.
bun run lint, all 24 CI audits,check:migrations, and type-check pass. 56 tests pass inpackages/db, including cases asserting the second pass walks on the shared implementation (lock before delete,statusre-checked) and that it registers under its own name.Checklist