refactor(release,cli): drop migration-ceiling CI step and CLI ceiling fetch#30139
Conversation
… fetch Removes the 'Compute migration ceilings' step from release.yml and dev-release.yaml (the node script that parsed migration registries to produce db_version + ws_id), and strips db_migration_version / last_workspace_migration_id from the register-release JSON payload. Updates cli/src/lib/upgrade-lifecycle.ts: drops the pre-Docker-swap migration rollback (which fetched the target ceiling from GET /v1/releases/?stable=true) and makes the post-swap rollback unconditional with rollbackToRegistryCeiling=true. The daemon self-derives the ceiling from its own baked-in registry; no external fetch is needed. Companion platform PR drops the columns from AssistantRelease entirely.
![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: cb0eca49f7
ℹ️ About Codex in GitHub
Codex has been enabled to automatically 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 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| if (ready) { | ||
| // Success path | ||
|
|
There was a problem hiding this comment.
This change makes migration rollback happen only after waitForReady() succeeds, so any target image that cannot boot against the newer DB/workspace schema will never get a chance to downgrade its migrations and the rollback will always fail back to the current version. In performDockerRollback, rollbackMigrations(..., rollbackToRegistryCeiling: true) now runs only inside the success branch, which removes the previous pre-swap safety path and breaks rollbacks to versions that require schema rollback before startup.
Useful? React with 👍 / 👎.
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| // Post-swap migration rollback: ask the now-running old daemon to roll | ||
| // back any migrations above its own registry ceiling. | ||
| await rollbackMigrations( | ||
| entry.runtimeUrl, | ||
| entry.assistantId, | ||
| undefined, | ||
| undefined, | ||
| true, | ||
| ); |
There was a problem hiding this comment.
🚩 Semantic change: migration rollback now always deferred to post-swap daemon
Previously, performDockerRollback attempted to roll back migrations on the CURRENT (newer) daemon before swapping containers, using specific target versions from the releases API. Only if that failed would it fall back to post-swap rollbackToRegistryCeiling on the TARGET (older) daemon. Now, migration rollback always happens post-swap via rollbackToRegistryCeiling (lines 706-712). This means the older daemon is now solely responsible for rolling back migrations introduced by the newer version. This works because rollbackToRegistryCeiling tells the daemon to revert anything above its own known migration set — the daemon's rollback handler has the necessary down() logic for migrations in its registry. This is a valid simplification, but it does mean that if a newer version introduced migrations whose rollback logic isn't present in the older version's codebase, those migrations won't be rolled back. This appears to be an accepted trade-off based on the PR's design.
Was this helpful? React with 👍 or 👎 to provide feedback.
1 participant
Summary
Drops the migration-ceiling CI step and the CLI ceiling fetch, completing the last actively harmful parts of the
db_migration_version/last_workspace_migration_iddecommission.What's removed
release.yml+dev-release.yaml— "Compute migration ceilings" step deleted:node -escript that parsedassistant/src/memory/migrations/registry.tsforDB_VERSIONnode -escript that walkedWORKSPACE_MIGRATIONSforWS_ID--argjson db_migration_version+--arg last_workspace_migration_idjq args in the register-release payloaddb_migration_version: $db_migration_version+last_workspace_migration_id: $last_workspace_migration_idJSON fieldscli/src/lib/upgrade-lifecycle.ts(performDockerRollback):fetch(platformUrl + '/v1/releases/?stable=true')block that pulled target ceiling from the public endpointlet targetMigrationCeiling = {}variable and the pre-swap migration rollbackifblock (the conditional rollback call on the current daemon before image swap)rollbackMigrations(..., true)— the newly-started old daemon self-derives its ceiling viarollbackToRegistryCeiling: trueWhy it's safe
The daemon has supported
rollbackToRegistryCeiling: truesince PR #6257. After image swap, the running daemon knows its own baked-in ceiling. No external fetch needed.Decommission scoreboard
capture_migration_statewrites + strip columns fromLatestStableReleaseResponseSerializer