fix(db): reorder 0012 timestamp after 0011 so drizzle-kit applies it - #687
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
![cubic-dev-ai[bot]](https://avatars.githubusercontent.com/in/1082092?s=60&v=4){kind=small}
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8dd4391ea5
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| "idx": 12, | ||
| "version": "7", | ||
| "when": 1779948193133, | ||
| "when": 1780150000000, |
There was a problem hiding this comment.
This directly changes a drizzle/meta/_journal.json timestamp, but the repo-level AGENTS.md Migration journal hygiene rule says to never hand-edit journal timestamps/sequence numbers and to use drizzle-kit generate to claim or repair migration slots; it also calls the 0010/0011 hand-edited timestamps a one-time historical exception. For this migration-ordering fix, please regenerate/repair the migration metadata through the Drizzle workflow rather than committing another manual when edit, otherwise future branches can inherit metadata that bypasses the repo's conflict-avoidance process.
Useful? React with 👍 / 👎.
The 2026-05-25 schema audit hand-rolled when=1780000000000 (0010) and 1780086400000 (0011). 0012 was generated normally by drizzle-kit generate and got when=1779948193133 (Feb 24), which is EARLIER than the hand-rolled 0010/0011 timestamps (Feb 25). drizzle-kit migrate sorts by when, so 0012 was placed before 0010 in the apply sequence. On any DB where 0010/0011 were already present, drizzle considered the prefix-through-0011 already-applied and silently skipped 0012. Result: production sessions table never got the token → token_hash rename and every /api/auth/session request 500'd with 'column sessions.token_hash does not exist'. Fix: bump 0012's when to 1780150000000 (between 0011's 1780086400000 and 0013's 1780172800000), restoring the intended monotonic ordering. The matching __drizzle_migrations row on prod has been inserted with the same when value and the file's SHA256 hash so drizzle-kit migrate will not try to re-apply. Confidence: high Scope-risk: narrow Directive: Never hand-roll _journal.json timestamps (the rule is already in AGENTS.md 'Migration journal hygiene'). The hand-rolled 0010/0011 timestamps are now boxed in by 0012/0013; do not introduce new hand-rolled values, and check ordering whenever editing the journal.
drizzle stores SHA256(file content) in drizzle.__drizzle_migrations on first apply and compares against the local file hash on every subsequent drizzle-kit migrate run. A comment-only edit changes the SHA256 and makes drizzle attempt to re-apply, which fails on non-idempotent DDL. This bit prod on 2026-06-08: the audit batch added a -- IMPORTANT lock- window comment to 0011_drop_dead_columns.sql AFTER it had been deployed. The local hash diverged from the prod __drizzle_migrations row, leaving drizzle in a state where the next migrate run would have tried to drop columns that no longer exist. Recovered with a one-off UPDATE on the prod journal row's hash. The rule in this commit prevents the next instance. Confidence: high Scope-risk: narrow Directive: For after-the-fact migration documentation (lock windows, rollback notes), use a sidecar 0NNN_<tag>.md or comments in schema.ts / AGENTS.md — never inside the applied .sql.
20f5ac8 to
38de12e
Compare
1 participant
Why prod was 500'ing
After merging #675, every
/api/auth/sessionand/leaderboardSSR request started failing withcolumn sessions.token_hash does not exist. Migration0012_hash_browser_session_tokens.sql(from #625) renamessessions.token → token_hash, but it never ran on production even thoughdrizzle-kit migrateclaimed success.Root cause
The 2026-05-25 schema audit hand-rolled
when=1780000000000(0010) and1780086400000(0011). When 0012 was generated bydrizzle-kit generatelater, it got the real-clock valuewhen=1779948193133(Feb 24, 2026), which is earlier than the hand-rolled 0010/0011 timestamps (Feb 25).drizzle-kit migratesorts the journal bywhenbefore applying. On any DB where 0010/0011 had already been applied, drizzle considered the prefix-through-0011 already-applied and silently skipped 0012. Then 0013 (mcp_servers) applied cleanly because itswhenis the latest. Result: prod'ssessionstable never got renamed.Fix
Bump
0012.whento1780150000000so it sits between0011.when=1780086400000and0013.when=1780172800000, restoring monotonic ordering.Already done on production
0012SQL applied by hand against prod (sessions table now hastoken_hash)drizzle.__drizzle_migrationsrow inserted for0012with the matching SHA256 (782891d5...) and the newwhen=1780150000000, sodrizzle-kit migratewill not try to re-applyTest plan
/api/auth/session→ 200 on prod (was 500)/leaderboardSSR → renders 50 ranked users, no console errors (was Server Components render error)drizzle-kit migratereports zero migrations to apply (the matching journal row should already be in__drizzle_migrations)Summary by cubic
Reordered migration 0012 by bumping its
whensodrizzle-kitapplies it after 0011 and before 0013, fixing thesessions.token → token_hashrename and the 500s. Added a docs rule: never edit applied migration SQL; use a sidecar note to avoid hash mismatches that makedrizzle-kittry to re-apply.Written for commit 38de12e. Summary will update on new commits.