Repository navigation
fix(cli): Keep the local database usable across CLI downgrades - #1612
sentry-junior[bot] wants to merge 5 commits into
Conversation
Switching from nightly back to stable left cli.db at a newer schema. The older CLI only migrates forward, so its org_regions upsert failed against the newer composite key and its login lookup found an empty auth table. - Before `cli upgrade` installs an older version, drop cache tables, copy the active account into the legacy auth/user_info tables, and set the schema version to 16 so the newer CLI re-migrates when it comes back. - Make the v18 accounts migration refresh an existing account instead of adding a duplicate when it re-runs. - When a newer CLI wrote the database, rebuild cache tables and record this version, or report it in `cli fix` when auto-repair is disabled. - Compare every table's primary key during repair, not only composite keys, and never drop a table whose data cannot be rebuilt. Fixes #1611 Co-Authored-By: Burak Yigit Kaya <burak.kaya@sentry.io>
|
The latest updates on your projects. Learn more about Vercel for GitHub. 1 Skipped Deployment
|
Another invocation of the newer CLI during the download re-migrates the database and undoes the hand-off, so `cli upgrade` now runs it again after installing. It skips a database already at schema 16, which keeps any login the older CLI wrote. When the older CLI logged out, `auth` comes back empty. The v18 migration now drops the handed-down active account instead of logging back in.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit dd06635. Configure here.
The post-install pass treated any version above 16 as a re-migration by the newer CLI, so it also undid forward migrations the older CLI's own `cli setup` ran. Only this CLI migrates to its own version, so skip everything below it.
BYK
left a comment
There was a problem hiding this comment.
A cheaper alternative rather than trying to revert the db from code can be backing up the db along with the version the user is coming from and introducing a sentry cli revert or sentry cli upgrade undo or something like that which restores the previous db and database. This can be tracked in a separate issue while we do the resilience patches in this PR.
Per review: rather than keep the pre-v18 `auth`/`user_info` schema in newer CLIs just for downgrades, the hand-off now clears stored accounts and the user logs in again in the older CLI. Coming back up, the v18 migration folds any login made there into `accounts` as before, so the token-matching and logout handling it gained in this PR are reverted. The hand-off only runs when the target predates 0.48.0, the first release that adapts a newer CLI's database itself.
Running the downgrade hand-off before the download meant a failed download left the current CLI logged out. It now runs right before the older binary's `cli setup`, and again in a `finally` after it, so a setup failure still redoes it if another invocation re-migrated the database in the meantime.

Fixes #1611.
Running nightly migrates
cli.dbto schema 19. Going back to stable 0.47.0 (schema 16) then breaks in two ways, because older CLIs only migrate forward:org_regionskeeps the v17 composite key, so 0.47'sON CONFLICT(org_slug)upsert fails with "ON CONFLICT clause does not match…". Its auto-repair only checks composite keys, so it never fixes this.authintoaccounts. 0.47 recreates an emptyauthtable on startup, so the user is logged out without being told.0.47.0 has already shipped, so the fix has to come from the newer CLI, which is the one running
sentry cli upgrade stable:cli upgradetargets a release below0.48.0, the first release that adapts a newer database by itself, it hands the database to the older CLI. It drops the cache tables (the older CLI recreates them in its own shape), deletes the stored accounts, and sets the schema version to 16. The older CLI can't readaccounts, so the user runssentry auth loginthere. This is simpler than keeping the old login format alive in newer CLIs.cli setup. A failed download leaves the database and login untouched. It runs again after setup, even if setup fails, in case another invocation of the newer CLI re-migrated the database meanwhile. That second run does nothing unless the version is the running CLI's own, so it can't undo migrations the older CLI ran itself.accounts.SENTRY_CLI_NO_AUTO_REPAIR=1,sentry cli fixreports the mismatch instead (CLI crashes with "ON CONFLICT clause does not match any PRIMARY KEY or UNIQUE constraint" after switching from nightly back to stable #1611 noted it used to print the binary's version and "No issues found").pragma_table_info, not just composite keys. Tables are markedrebuildablewhen they only hold derived data. Only those get dropped and recreated; a wrong key on any other table is reported and left alone.Every migration after v16 now has to be safe to re-run. This is documented on
prepareDatabaseForDowngrade.The
0.48.0threshold assumes this PR lands before 0.48.0 is released.Backing up
cli.dbon upgrade and adding an undo command, which would keep the login across a downgrade, is tracked in #1623.via BYK.
--
View Junior Session [Sentry]