Sync silently freezes after catalog repair — UNIQUE constraint failed: AgDNGProxyInfo.id_local

Summary

After Lightroom Classic repaired a corrupted catalog, cloud sync froze indefinitely ("Syncing 186 photos") with no error shown anywhere in the UI. The console log shows the sync engine repeatedly failing to write its DNG-proxy bookkeeping rows because it re-uses row IDs that already exist: the repair left the catalog (.lrcat) and the sync store (Sync.lrdata) restored to inconsistent points in time. Each app relaunch synced exactly ~20 more assets before freezing again. Rebuilding sync data (renaming Sync.lrdata) resolved it completely.

Environment

• Lightroom Classic 15.5 on macOS 26.4.1 (build 25E253), Apple Silicon
• ~432 MB catalog, sync enabled to Lightroom cloud
• Affected assets: JPEG film scans, which go through DNG-proxy conversion for sync

Steps that led to the bug

1. Catalog became corrupted mid-session while sync had ~186 assets queued (the sync engine had just written a batch of new proxy records to AgDNGProxyInfo).
2. Repaired the catalog with the built-in repair on next launch.
3. Sync resumed, uploaded ~20 assets, then froze — indefinitely, with no visible error. The cloud panel showed "Syncing 186 photos" forever.

What the logs show

Within about a minute of every launch, lrc_console.log records bursts of:

Bad sqlite return code: 1555. Info: UNIQUE constraint failed: AgDNGProxyInfo.id_local
Database ".../Lightroom Catalog.lrcat": UNIQUE constraint failed: AgDNGProxyInfo.id_local
  sql: INSERT INTO AgDNGProxyInfo
       ( fileUUID, id_local, status, statusDateTime )
       VALUES ( ?, ?, ?, datetime( 'now' ) )  (error code 1555)
   ...
   10: field    updateProxyUUIDForImage

immediately preceded by the DNG conversion step for the queued film scans ("Warning: convert to digital negative without metadata"). After 4–7 failures the engine backs off and the queue freezes for the rest of the session. Roughly 20 assets complete per relaunch — the pending count went 186 → 166 → 146 across three consecutive sessions, freezing each time.

Root cause (from inspecting the databases directly)

The catalog repair restored Lightroom Catalog.lrcat and Lightroom Catalog Sync.lrdata to inconsistent points in time. The sync engine then replays proxy-record inserts using row IDs it had already consumed before the crash, so every INSERT collides with an existing primary key. Two observations that narrow it down:

• The colliding IDs do not come from Adobe_variablesTable.Adobe_entityIDCounter — setting that counter far above every existing id_local in the catalog did not stop the collisions.
• Deleting the previously written AgDNGProxyInfo rows did not stop them either. The replayed IDs come from allocation state persisted inside Sync.lrdata.

Workaround that fixed it

Quit Lightroom Classic, rename Lightroom Catalog Sync.lrdata, relaunch. Lightroom rebuilt the sync data and the entire backlog uploaded in minutes with zero errors.

Two defects to fix

1. Consistency after repair. Catalog repair should also reset or validate the sync store, or the proxy-record insert should tolerate an ID collision (re-allocate or upsert) instead of failing forever. A repair should never leave sync permanently wedged.
2. Silent failure. A database error that halts sync is never surfaced to the user — the UI just shows "Syncing N photos" indefinitely. Errors of this class should appear in the UI the way per-asset sync errors already do, so users aren't left restarting the app blindly.