Skip to content

fix(cli): Keep the local database usable across CLI downgrades - #1612

Open
sentry-junior[bot] wants to merge 5 commits into
mainfrom
fix/cli-db-newer-schema-downgrade
Open

sentry-junior[bot] wants to merge 5 commits into
mainfrom
fix/cli-db-newer-schema-downgrade

Conversation

@sentry-junior

@sentry-junior sentry-junior Bot commented Oct 23, 2026 •

Copy link
Copy Markdown
Contributor

Fixes #1611.

Running nightly migrates cli.db to schema 19. Going back to stable 0.47.0 (schema 16) then breaks in two ways, because older CLIs only migrate forward:

  • org_regions keeps the v17 composite key, so 0.47's ON CONFLICT(org_slug) upsert fails with "ON CONFLICT clause does not match…". Its auto-repair only checks composite keys, so it never fixes this.
  • v18 moved the login from auth into accounts. 0.47 recreates an empty auth table 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:

  • Downgrade hand-off: when cli upgrade targets a release below 0.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 read accounts, so the user runs sentry auth login there. This is simpler than keeping the old login format alive in newer CLIs.
  • When it runs: only after the older binary is downloaded, right before it runs 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.
  • Upgrading back: the newer CLI re-runs migrations 17–19 from version 16 and moves any login made on the older CLI into accounts.
  • Future downgrades through other paths (npm/brew pinning): if the stored version is newer than the binary, the CLI rebuilds every cache table and records its own version. A newer CLI can change what cached rows mean, so they can't be trusted. With SENTRY_CLI_NO_AUTO_REPAIR=1, sentry cli fix reports 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").
  • Repair now compares every table's primary key using pragma_table_info, not just composite keys. Tables are marked rebuildable when 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.0 threshold assumes this PR lands before 0.48.0 is released.

Backing up cli.db on upgrade and adding an undo command, which would keep the login across a downgrade, is tracked in #1623.

via BYK.

--

View Junior Session [Sentry]

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>
@vercel

vercel Bot commented Oct 23, 2026 •

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment
Project Deployment Actions Updated
sentry-local Skipped Skipped Oct 23, 2026 11:36am UTC

Request Review

@cursor cursor Bot left a comment •

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Stale Bugbot comment from a previous run.

Comment thread packages/cli/src/commands/cli/upgrade.ts Outdated
Comment thread packages/cli/src/lib/db/schema.ts Outdated
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.
@github-actions github-actions Bot added risk: high PR risk score: high risk: medium PR risk score: medium and removed risk: medium PR risk score: medium risk: high PR risk score: high labels Oct 23, 2026

@cursor cursor Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Fix All in Cursor

❌ 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.

Comment thread packages/cli/src/commands/cli/upgrade.ts Outdated
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 BYK left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread packages/cli/src/lib/db/schema.ts Outdated
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.
Comment thread packages/cli/src/commands/cli/upgrade.ts Outdated
Comment thread packages/cli/src/commands/cli/upgrade.ts Outdated
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.
@github-actions github-actions Bot added risk: high PR risk score: high and removed risk: medium PR risk score: medium labels Oct 23, 2026
@github-actions github-actions Bot added risk: medium PR risk score: medium and removed risk: high PR risk score: high labels Oct 23, 2026

This branch was previously deployed

1 inactive deployment
Preview — d7aae4eb Deployed Oct 23, 2026 by vercel[bot]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

risk: medium PR risk score: medium

Projects

None yet

Development

Successfully merging this pull request may close these issues.

CLI crashes with "ON CONFLICT clause does not match any PRIMARY KEY or UNIQUE constraint" after switching from nightly back to stable

1 participant