OUT-3645: tombstone-based sync recovery + ON CONFLICT alignment

[SandipBajracharya]

Summary

Replaces ad-hoc retry logic with a tombstone-based recovery model for failed sync operations, plus the partial-unique-index work from OUT-3778 (included in this stack because the runtime code in this PR depends on those indexes).

What's in this PR

Tombstone-based recovery (OUT-3645)

• Adds pending_action, pending_action_target, pending_action_attempts, pending_action_last_attempt_at, pending_action_last_error columns to file_folder_sync.
• Pre-insert pattern for creates in both directions: a tombstone row is inserted before the Assembly/Dropbox API call, then completed (or marked failed for the sweeper to retry) afterwards.
• New markAttempt / markUpdated / markDeleted / markFailure helpers on MapFilesService.
• completePendingAssemblyCreate / completePendingDropboxCreate shared between the original create flow and the sweeper retry path.
• Scheduled Trigger.dev sweep (0 8,20 * * * — twice daily at 08:00 and 20:00 UTC, chosen as off-peak hours) replaces the previous Vercel cron; dispatches retries by (action, target).
• Shared normalizeError utility.

Partial unique indexes (OUT-3778, bundled)

• Two partial unique indexes on file_folder_sync:
  • (portal_id, channel_sync_id, assembly_file_id) WHERE deleted_at IS NULL AND assembly_file_id IS NOT NULL
  • (portal_id, channel_sync_id, dbx_file_id) WHERE deleted_at IS NULL AND dbx_file_id IS NOT NULL
• The IS NOT NULL guards in the WHERE keep the index lean (Greptile P2 fix).
• Migration uses CREATE UNIQUE INDEX IF NOT EXISTS so it's idempotent.

ON CONFLICT alignment

• insertCreatePending's ON CONFLICT WHERE clause is now target-aware to match the narrowed partial-index predicates. Without this, PG throws no unique or exclusion constraint matching the ON CONFLICT specification at runtime.

Known accepted regressions (documented for reviewers)

• Rows stuck at pending_action_attempts = MAX_ATTEMPTS mask the file from the bidirectional sync filter. Operational monitoring needed.
• Concurrent user updates during the pre-create window (seconds) can be silently dropped.
• Stale single-ID mapping rows mask the corresponding source file.
• Sweeper cadence is twice a day, so transient remote-API failures can take up to ~12 hours to recover (vs. the previous ~15 min cadence). The user-triggered Resync button (OUT-3784) is the immediate-recovery path.

Pre-deploy checklist

• Audit existing prod data for duplicates before applying the partial index migration — audit queries are in the migration file's header comments. If either returns rows, resolve before deploy.
• One-time SQL backfill for pre-PR-2 legacy rows (pending_action IS NULL AND content_hash IS NULL). User-handled separately.

Test plan

• pnpm typecheck clean
• pnpm lint clean
• pnpm test passes (tombstone helpers + ResyncService per-portal fan-out + Sweeper retry paths)
• Manual: trigger a sync that fails mid-flight (e.g. revoke Dropbox token for a moment), verify tombstone row is created and the sweeper retries it on the next tick.
• Manual: verify ON CONFLICT path in insertCreatePending doesn't throw under concurrent creates of the same file.

🤖 Generated with Claude Code

[linear-code]

OUT-3645

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
dropbox-integration	Ready	Preview, Comment	May 29, 2026 9:41am

[greptile-apps]

Greptile Summary

This PR replaces ad-hoc retry logic with a tombstone-based recovery model: a pending_action row is pre-inserted before every remote API call, then resolved to a full mapping or left for a Trigger.dev scheduled sweep (twice daily at 08:00 and 20:00 UTC) to retry. Two partial unique indexes with IS NOT NULL guards are added to prevent duplicate live rows, and the ON CONFLICT clause in insertCreatePending is aligned to match their WHERE predicates.

• Tombstone lifecycle: insertCreatePending now stamps pendingActionLastAttemptAt = new Date() on insert, shielding in-flight creates from the sweeper; markAttempt / markUpdated / markDeleted / markFailure helpers manage state transitions.
• Sweeper: retryFailedSyncsSchedule replaces the old Vercel cron route; ResyncService fans out per-portal retries via resyncFailedFilesInAssembly Trigger.dev tasks with a per-row exponential backoff.
• Idempotency asymmetry: completePendingDropboxCreate delegates to createAndUploadFileInDropbox which checks for an existing Dropbox file before creating; completePendingAssemblyCreate calls copilotApi.createFile unconditionally, so a retry after a partial failure (API call succeeded, markUpdated failed) creates a second Assembly file.

Confidence Score: 3/5

The sweep retry path can create duplicate Assembly files when a remote API call succeeds but the DB update fails; this is a real defect on the newly added retry code path that warrants a fix before deploy.

completePendingAssemblyCreate calls copilotApi.createFile unconditionally on every retry attempt. If a previous sweep's createFile returned successfully but the subsequent markUpdated failed (transient DB error), the row retains pendingAction = 'create' and assemblyFileId = null. The next sweep fires createFile again, producing a second Assembly file with no cleanup path. The Dropbox direction already guards against this by checking whether the file exists before uploading.

src/features/sync/lib/Sync.service.ts — specifically completePendingAssemblyCreate, which lacks the idempotency guard present in its Dropbox counterpart.

Important Files Changed

Filename	Overview
src/features/sync/lib/Sync.service.ts	Adds completePendingAssemblyCreate and completePendingDropboxCreate shared between the initial sync path and the sweeper; the Dropbox direction is idempotent but the Assembly direction calls createFile unconditionally on every retry, risking duplicate Assembly files if markUpdated fails after a successful API call.
src/features/workers/resync-failed-files/lib/resync-failed-files.service.ts	New ResyncService with findFailedSyncs + resyncFailedFiles; backoff formula and attempt-cap logic are correct, but findMany has no row limit, which could push oversized payloads into Trigger.dev.
src/features/workers/resync-failed-files/helper/resync-failed-files.helper.ts	Per-portal retry helpers for all four (action, target) combinations; DELETE paths are idempotent (404/not_found handled), CREATE paths delegate to the shared completePending* methods; getFileFromDropbox still swallows all errors (flagged in a previous review cycle).
src/features/sync/lib/MapFiles.service.ts	Adds insertCreatePending, markAttempt, markUpdated, markDeleted, markFailure; tombstone insertion now stamps pendingActionLastAttemptAt = new Date() to guard in-flight rows from the sweeper. Logic looks correct.
src/trigger/processFileSync.ts	Adds resyncFailedFilesInAssembly task and retryFailedSyncsSchedule (0 8,20 * * *); removes the old Vercel-cron-based route. Schedule and concurrency limits look reasonable.
src/db/migrations/20260526094109_add_unique_indexes_on_portal_channel_assembly_and_dbx_file.sql	Two partial unique indexes with IS NOT NULL guards; IF NOT EXISTS makes the migration idempotent; audit queries in comments are appropriate.

Sequence Diagram

sequenceDiagram
    participant Sched as retryFailedSyncsSchedule
    participant RS as ResyncService
    participant DB as Database
    participant TDev as Trigger.dev
    participant Helper as retryFailedSyncsForPortal
    participant Sync as SyncService
    participant API as Assembly / Dropbox API

    Sched->>RS: resyncFailedFiles()
    RS->>DB: findFailedSyncs()
    DB-->>RS: rows[]
    RS->>RS: group rows by portalId
    RS->>TDev: resyncFailedFilesInAssembly.trigger(portalId, rows)
    TDev->>Helper: retryFailedSyncsForPortal(portalId, rows)
    Helper->>Helper: initializeSyncDependencies()
    loop for each failedSync row
        Helper->>Sync: markAttempt(id, action, target)
        alt "action=CREATE target=DROPBOX"
            Helper->>API: copilotApi.retrieveFile
            Helper->>Sync: completePendingDropboxCreate
            Sync->>API: createAndUploadFileInDropbox [idempotent]
            Sync->>DB: markUpdated(id, dbxFileId)
        else "action=CREATE target=ASSEMBLY"
            Helper->>API: getFileFromDropbox
            Helper->>Sync: completePendingAssemblyCreate
            Sync->>API: copilotApi.createFile [NOT idempotent]
            Sync->>DB: markUpdated(id, assemblyFileId)
        else "action=DELETE"
            Helper->>API: deleteFile or filesDeleteV2
            Helper->>DB: markDeleted(id)
        end
        note over Helper,DB: on error: markFailure(id, message)
    end

Loading

_{Reviews (3): Last reviewed commit: "fix(OUT-3645): reduce sweeper cadence to..." | Re-trigger Greptile}

[SandipBajracharya]

@greptileai

[SandipBajracharya]

@greptileai

[priosshrsth]

lgtm