Skip to content

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

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

Description

@Itz-Agasta
Itz-Agasta
opened on Oct 23, 2026

Environment

  • sentry CLI stable cli@0.47.0, installed as a Bun global (install.method bun in cli.db)
  • Previously ran nightly 0.48.0-dev.1792585391, which migrated ~/.config/sentry/cli.db to schema_version 19
  • Linux 6.18, Bun 1.4.4, sentry.io SaaS, one org with two projects

Steps to Reproduce

  1. sentry cli upgrade nightly, then run any authenticated command (the DB migrates to schema 19).
  2. sentry cli upgrade stable (or reinstall cli@0.47.0).
  3. sentry issue view <SHORT-ID> for an issue in a project the local DSN does not match, so the CLI has to list organizations.

Expected Result

sentry cli upgrade stable is the documented way back from nightly, so stable should cope with a DB from a newer schema: rebuild the cache tables, or refuse with a message saying what to do. sentry cli fix should catch the mismatch.

Actual Result

$ sentry issue view WEB-14 --json --fields shortId --log-level trace
[http] GET /api/0/organizations/ -> 200 (814ms)
Unexpected error: Error: ON CONFLICT clause does not match any PRIMARY KEY or UNIQUE constraint

After the nightly, org_regions has PRIMARY KEY (credential_identity, source_origin, org_slug) (packages/cli/src/lib/db/schema.ts, added for multi-account auth in #1526/#1528). 0.47.0 is schema 16 and upserts org_regions with ON CONFLICT(org_slug), which SQLite rejects. Short IDs resolved through the DSN shortcut never touch that table and keep working, so the failure looks random.

initSchema only migrates when currentVersion < CURRENT_SCHEMA_VERSION, so nothing notices a newer DB, including on main. sentry cli fix prints Schema version: 16 ... No issues found (the binary's version) while select version from schema_version returns 19. It could compare each table's primary key with the declared schema; hasCompositePrimaryKey already exists for pagination_cursors.

Workaround: drop and recreate org_regions (a cache table), or delete cli.db and log in again.

Activity

  1. linear-code commented on Oct 23, 2026

    @linear-code
    linear-codeBot
    on Oct 23, 2026 – with Linear Code

    MCP-1115

  2. sentry-junior commented on Oct 23, 2026

    @sentry-junior
    sentry-juniorBot
    on Oct 23, 2026
    Contributor

    Thanks for the detailed report — the diagnosis is spot on. Fix is up in #1612.

    To unblock 0.47.0 right now, drop the cache table; 0.47.0 recreates it in its own shape on the next run:

    sqlite3 ~/.config/sentry/cli.db 'DROP TABLE org_regions'

    (Use $SENTRY_CONFIG_DIR/cli.db if you set that.) Without sqlite3, rm ~/.config/sentry/cli.db and log in again also works.

    One more thing the downgrade breaks: schema 18 moved the stored login from auth into accounts, which 0.47.0 can't read, so stable starts out logged out. If sentry auth status says so, run sentry auth login. A SENTRY_AUTH_TOKEN keeps working either way.

    What #1612 changes

    • sentry cli upgrade stable (run from a nightly that has the fix) prepares the database for the older version before installing it. It clears the caches, copies the active login to where older versions read it, and lowers the schema version so the newer CLI re-migrates when you upgrade again.
    • A CLI that finds a database written by a newer version rebuilds its caches instead of crashing. With SENTRY_CLI_NO_AUTO_REPAIR=1, sentry cli fix reports the version mismatch instead of "No issues found".
    • Schema repair now checks every table's primary key, not only composite ones.

    0.47.0 itself can't be patched. To go nightly → stable before #1612 ships in a nightly, use the workaround above.

  3. sentry-junior commented on Oct 23, 2026

    @sentry-junior
    sentry-juniorBot
    on Oct 23, 2026
    Contributor

    Correction to my comment above: #1612 changed during review. sentry cli upgrade stable no longer copies your login over to the older CLI.

    Once the older CLI is downloaded, the upgrade clears the caches and the stored login and lowers the schema version. After downgrading you'll need to run sentry auth login again on stable. When you upgrade again, the newer CLI re-migrates and keeps any login you made on stable. A SENTRY_AUTH_TOKEN keeps working either way.

    Keeping the login across a downgrade (back up cli.db on upgrade and restore it with an undo command) is tracked in #1623. The workaround above still applies to 0.47.0 today.

  4. sentry-junior
    added a commit that references this issue on Oct 27, 2026

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

    c80c945
  5. BYK
    closed this as completedin #1612on Oct 27, 2026
  6. sentry-junior
    added 2 commits that reference this issue on Oct 27, 2026

    fix(cli): Keep the database as is when a hand-off setup fails

    68d9123

    fix(cli): Reinstate the database after a failed undo that needed a ha…

    4483a90
  7. BYK
    added a commit that references this issue on Oct 27, 2026

    feat(cli): Back up the database on upgrade and add `cli upgrade undo` (…

    0315e47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions