fix(sql-editor): bind Backup restore to migrated connection; stop corrupting snapshots

[cursor]

Bug and impact

Two critical defects in Compare Data Backup / Restore (SQL Editor side-by-side migrate):

1. Wrong-database restore — Restore always executed reverse INSERT/UPDATE/DELETE on the current Compare Destination (dest.connectionId). After a partial migrate to credential B, switching Destination to C (3+ credentials) or opening History while C is selected could reverse DML onto C.
2. Silent snapshot corruption — History capped snapshot_json at 1MB by appending \n… (truncated), which is invalid JSON. Save still succeeded, History still offered Restore, and JSON.parse always failed — so the durable undo safety net after a partial migrate was silently ruined (especially after reload).

Root cause

• Restore path never recorded which connection was migrated; it reused the live Destination picker.
• cap() was shared for free-text scripts and machine-parsed snapshot JSON; truncation markers are fine for scripts, fatal for JSON.

Fix

• Embed connectionId in the Backup snapshot; Restore always targets that credential (refuse if missing / credential deleted). Legacy snapshots without connectionId only restore when the current Destination still matches the recorded target host/database.
• Capture connection id at apply time for toast / in-memory Restore so a later Destination switch cannot redirect the action.
• Replace snapshot cap() with omit-if-too-large / reject-if-non-JSON; return snapshotStored from /data-migrations/start and warn when History could not keep the backup. Hide Restore for unusable History snapshots.

Validation

• npx vitest run on dataMigratePlans.test.ts + data-migrate-history.module.test.ts — 16 passed
• cd apps/web && npx tsc --noEmit — clean

  

---

Note

High Risk
Changes DML execution targets for Restore and how backup snapshots are persisted—wrong-connection restore was a data-corruption class bug; fixes are correctness-critical for partial migrate undo.

Overview
Fixes Compare Data Backup / Restore so undo DML runs on the database that was actually migrated, and History no longer stores broken snapshot JSON that still offered Restore.

Restore targeting — Backup snapshots now include the destination connectionId. Restore (toast, in-session backup, and History) executes reverse DML on that credential instead of whatever Compare Destination is selected later. Migrate-time connection id is captured for toast actions; missing or deleted credentials block restore with a clear message. Older snapshots without connectionId only restore when the current Destination still matches recorded target host/database.

Snapshot storage — Replaces truncating snapshot_json with a truncation marker (invalid JSON) with storeableSnapshotJson: store only intact parseable JSON under the 1MB cap, or omit and report snapshotStored: false from /data-migrations/start. Scripts still truncate for display via capScript. UI warns when backup is session-only; History hides Restore for unusable snapshots and shows an error for legacy truncated entries.

Tests cover storeableSnapshotJson, snapshot connectionId, and isUsableDataMigrateSnapshot.

^{Reviewed by Cursor Bugbot for commit e48b203. Bugbot is set up for automated code reviews on this repo. Configure here.}

[cursor]

Bugbot couldn't run - usage limit reached

Bugbot is counted against Cursor usage for this user or team, and this run hit a usage or spend limit.

A user or team admin can review and increase usage limits in the Cursor dashboard.

(requestId: serverGenReqId_c8cc2fd6-f455-4cf6-8e51-68779d42847a)