lz/agent-nexus
lz/agent-nexus
1
0
Fork 0
Code Issues 40 Pull requests 5 Projects Releases Packages 2 Wiki Activity Actions 1

chore(db): land migration 0017 ahead of the #96 release candidate #104

Merged
lz merged 1 commit from chore/migration-0017-ahead-of-rc into main 2026-09-04 00:20:31 +02:00
Conversation 0 Commits 1 Files changed 1 +25
lz commented 2026-09-04 00:07:32 +02:00
Owner
Copy link

Schema only — deliberately separated from the code that writes these columns (#99), so the #96 release candidate can be rolled back by swapping the image and nothing else.

Why this is split out

Kysely's migrator refuses to start against a database holding a migration the code does not know about. Measured against this repo's own migration set:

old-code boot error : Error: corrupted migrations:
                      previously executed migration 0017_provision_detail is missing

runMigrations rethrows that, and server.ts runs migrations explicitly at boot — so a main-built image pointed at a database the RC had already migrated would not start at all. Not degrade: refuse to boot.

Nothing is actually incompatible. Both columns are nullable, display-only, and never read by main's code. It is purely the strictness check.

Landing the migration here first means the RC carries no schema change, so main and the RC are interchangeable in both directions and rollback is a pure image swap.

Merge safety

The file is byte-identical to the copy on feat/startup-visibility, so the stack merges it clean when it lands. Verified with git merge-tree:

0017 x #99 (feat/startup-visibility)   clean
0017 x stack tip (feat/ports-and-probes)  clean

Gates

108 files / 1013 tests passed
typecheck  4855 FILES  0 ERRORS  0 WARNINGS
lint       clean

Deploy order

  1. Merge this, deploy main — the schema is now present in production.
  2. Deploy the RC — no migrations run.
  3. Roll back if needed by redeploying the previous image. No DB surgery.

Take a VACUUM INTO snapshot before step 2 anyway; it costs one command.

Schema only — deliberately separated from the code that writes these columns (#99), so the #96 release candidate can be rolled back by swapping the image and nothing else. ## Why this is split out Kysely's migrator refuses to start against a database holding a migration the code does not know about. Measured against this repo's own migration set: ``` old-code boot error : Error: corrupted migrations: previously executed migration 0017_provision_detail is missing ``` `runMigrations` rethrows that, and `server.ts` runs migrations explicitly at boot — so a **main-built image pointed at a database the RC had already migrated would not start at all.** Not degrade: refuse to boot. Nothing is actually incompatible. Both columns are nullable, display-only, and never read by main's code. It is purely the strictness check. Landing the migration here first means the RC carries **no schema change**, so main and the RC are interchangeable in both directions and rollback is a pure image swap. ## Merge safety The file is byte-identical to the copy on `feat/startup-visibility`, so the stack merges it clean when it lands. Verified with `git merge-tree`: ``` 0017 x #99 (feat/startup-visibility) clean 0017 x stack tip (feat/ports-and-probes) clean ``` ## Gates ``` 108 files / 1013 tests passed typecheck 4855 FILES 0 ERRORS 0 WARNINGS lint clean ``` ## Deploy order 1. Merge this, deploy main — the schema is now present in production. 2. Deploy the RC — no migrations run. 3. Roll back if needed by redeploying the previous image. No DB surgery. Take a `VACUUM INTO` snapshot before step 2 anyway; it costs one command.
chore(db): land 0017 ahead of the issue-96 release candidate
All checks were successful
ci / nexus (pull_request) Successful in 8m13s
Details
ci / images (pull_request) Successful in 7m52s
Details
pr-image-cleanup / delete-pr-images (pull_request) Successful in 7s
Details
a0492d1c9c 
Schema only, deliberately separated from the code that writes these
columns (PR #99), so the #96 release candidate can be rolled back by
swapping the image and nothing else.

Kysely's migrator refuses to start against a database holding a migration
the code does not know about:

    Error: corrupted migrations: previously executed migration
    0017_provision_detail is missing

`runMigrations` rethrows that and server.ts runs migrations at boot, so a
main-built image pointed at a database the RC had already migrated would
not start at all. Nothing is actually incompatible — both columns are
nullable, display-only, and never read by this branch's code — it is purely
the strictness check. Landing the migration here first makes the RC carry
no schema change, so main and the RC are interchangeable in both directions.

The file is byte-identical to the copy on feat/startup-visibility, so the
stack merges it clean when it lands.
lz merged commit 3dac2779af into main 2026-09-04 00:20:31 +02:00
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
bug
Something is not working

  
duplicate
This issue or pull request already exists

  
enhancement
New feature

  
help wanted
Need some help

  
invalid
Something is wrong

  
question
More information is needed

  
wontfix
This won't be fixed

No labels
bug
duplicate
enhancement
help wanted
invalid
question
wontfix
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lz/agent-nexus!104
No description provided.