OUT-3784: add Resync button + per-channel orchestrator

[SandipBajracharya]

Summary

Adds a user-triggered "Resync" button on each active channel mapping. Click → resets attempt counters on tombstoned rows for that channel → triggers an orchestrator task that runs the failed-files retry followed by a full bidirectional sync. Per-channel serialization via concurrencyKey: channelSyncId. Stacks on top of OUT-3782 (#107).

What's in this PR

1. Retry-sync endpoint — POST /api/sync/resync
Verifies channel ownership, resets pendingActionAttempts = 0 and pendingActionLastAttemptAt = null on rows with active tombstones, stamps resyncingAt = NOW() on the channel, and enqueues the orchestrator. Wraps trigger() in try/catch and rolls back resyncingAt if the trigger.dev call itself fails.

2. New orchestrator task — resyncFailedFilesAndMasterSync
Trigger.dev task that:

• (if any rows) resyncFailedFilesInAssembly.triggerAndWait
• bidirectionalMasterSync.triggerAndWait for the channel
• finally block clears resyncingAt so the row never gets stuck in the resyncing state, even on failure.

Triggered with concurrencyKey: channelSyncId so multiple clicks for the same channel serialize; different channels run in parallel. The scheduled sweeper is unchanged — it continues calling the bare retry task, not the orchestrator.

3. resyncing_at timestamp column on channel_sync
New nullable timestamp column drives the "Resyncing..." UI state and survives page reloads via realtime.

4. UI — Resync button

• Visible on each active mapping row (mapItem.status === true).
• Disabled while mapItem.resyncingAt is set.
• "Last Updated" cell renders "Resyncing..." during the window.
• Silent on success, console.error on failure (matches existing patterns). Optimistic local update; realtime confirms via the channel UPDATE event.

5. Personal Dropbox accounts
ResyncService no longer requires rootNamespaceId to be non-null on the connection lookup — DropboxClient already accepts null and skips the namespace header for personal accounts.

Edge cases handled

• trigger() throws synchronously → orchestrator never runs → service rollback clears resyncingAt.
• Orchestrator throws mid-run → finally clears resyncingAt.
• Channel has zero pending rows → bidirectional still runs (user-clicked Resync means "force a refresh").
• Concurrent clicks → serialized by concurrencyKey per channel; doesn't pollute other channels.

Test plan

• pnpm typecheck clean
• pnpm lint clean
• pnpm test passes (orchestrator wiring + concurrencyKey + null rootNamespaceId + trigger-throws rollback)
• Manual: click Resync on a mapping that has tombstone rows, verify "Resyncing..." appears in Last Updated and the button is disabled. Wait for bidirectional to complete, confirm the row returns to "Active" and the button re-enables.
• Manual: hard-refresh the page mid-resync; verify "Resyncing..." persists (driven by resyncing_at from realtime).
• Manual: click Resync rapidly on the same channel; verify concurrencyKey serializes the runs.
• Manual: click Resync on two different channels; verify they run in parallel.

🤖 Generated with Claude Code

[linear-code]

OUT-3784

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
dropbox-integration	Ready	Preview, Comment	May 28, 2026 4:30am

[greptile-apps]

Greptile Summary

This PR adds a user-triggered "Resync" button to active channel mappings, backed by a new resync API endpoint, a resyncFailedFilesAndMasterSync trigger.dev orchestrator task, and a resyncing_at timestamp column on channel_sync that drives the "Resyncing…" UI state across page reloads via realtime.

• Endpoint and service (sync.controller.ts, resync-failed-files.service.ts): validates channel ownership (active, non-deleted, correct portal), guards against duplicate resyncs via resyncingAt, resets tombstone attempt counters on file_folder_sync, stamps resyncingAt, and enqueues the orchestrator with a rollback path if enqueueing fails.
• Orchestrator task (processFileSync.ts): runs resyncFailedFilesInAssembly.triggerAndWait (if rows exist) then bidirectionalMasterSync.triggerAndWait, with a finally block that always clears resyncingAt; a per-channel concurrency key serializes concurrent clicks for the same channel while allowing different channels to run in parallel.
• UI (Table.tsx, useTable.ts, useRealtimeSync.ts): optimistic local update on click, button disabled while resyncingAt is set, realtime confirms the server timestamp; personal Dropbox accounts with null rootNamespaceId are now supported.

Confidence Score: 5/5

Safe to merge. The feature is well-scoped, the channel-ownership and active-status guards are in place, and the rollback path on trigger failure is tested.

The core logic is solid: duplicate-resync guard, proper auth checks, try/catch rollback, and concurrency serialization are all correctly implemented and covered by tests. The two findings are non-blocking quality observations — a brief UI flicker on the rare 409 path (corrected by realtime), and oversized trigger payloads for channels with many large-error tombstones.

No files require special attention for merging.

Important Files Changed

Filename	Overview
src/features/workers/resync-failed-files/lib/resync-failed-files.service.ts	New resyncFailedFilesForChannel method: verifies channel ownership (status=true, !deletedAt), guards against duplicate resyncs via resyncingAt check, resets tombstone counters, stamps resyncingAt, triggers orchestrator with rollback on trigger failure. Logic is sound; full DB rows passed as trigger payload is a minor sizing concern.
src/trigger/processFileSync.ts	New resyncFailedFilesAndMasterSync orchestrator task: runs tombstone retries then bidirectional sync, with finally clearing resyncingAt. retry: { maxAttempts: 0 } is intentional to prevent double clearing. Clean implementation.
src/features/sync/hooks/useTable.ts	New useResyncChannel hook: optimistic UI update + API call + rollback on error. The catch-block rollback always clears resyncingAt locally including on 409 (where server has it set), creating a brief incorrect UI state before realtime corrects it.
src/features/workers/resync-failed-files/lib/tests/resync-failed-files.test.ts	Comprehensive tests added for resyncFailedFilesForChannel: covers not-found, 409-conflict, missing connection, happy path (with concurrencyKey assert), null rootNamespaceId, trigger-throws rollback, and zero-pending-rows cases.
src/features/sync/components/Table.tsx	Resync button added to active mapping rows, disabled while resyncingAt is set. "Resyncing…" replaces the Last Updated cell during resync. Logic is straightforward and correct.
src/features/sync/api/sync.controller.ts	New resyncChannelMapping controller: authenticates via token, validates body with ResyncChannelRequestSchema (z.uuid()), delegates to ResyncService. Clean and consistent with existing controller patterns.
src/db/migrations/20260527094016_add_resynced_at_column_in_channel_sync_table.sql	Simple nullable timestamp column addition via ALTER TABLE. Non-breaking, no default needed (null is the correct initial state).
src/features/sync/hooks/useRealtimeSync.ts	Adds resyncingAt to the realtime UPDATE merge, ensuring the UI reflects server state after page reloads or concurrent sessions.

Sequence Diagram

sequenceDiagram
    participant UI as Browser UI
    participant API as Resync Endpoint
    participant SVC as ResyncService
    participant DB as Database
    participant TR as Trigger.dev

    UI->>UI: optimistic setResyncingAt(now)
    UI->>API: POST channelSyncId
    API->>SVC: resyncFailedFilesForChannel()
    SVC->>DB: "findFirst channelSync (status=true, not deleted)"
    DB-->>SVC: channel or 404
    SVC->>SVC: guard: resyncingAt set? return 409
    SVC->>DB: "findFirst dropboxConnections (status=true)"
    DB-->>SVC: connection or 404
    SVC->>DB: UPDATE file_folder_sync reset attempt counters RETURNING
    DB-->>SVC: resetRows
    SVC->>DB: "UPDATE channel_sync set resyncing_at=NOW()"
    SVC->>TR: enqueue orchestrator (serialized per channel)
    alt enqueueing fails
        SVC->>DB: "UPDATE channel_sync set resyncing_at=NULL"
        API-->>UI: error response
        UI->>UI: rollback setResyncingAt(null)
    else enqueueing succeeds
        API-->>UI: 200 OK
        TR->>TR: resyncFailedFilesInAssembly.triggerAndWait (if rows)
        TR->>TR: bidirectionalMasterSync.triggerAndWait
        TR->>DB: "finally: UPDATE channel_sync set resyncing_at=NULL"
        DB-->>UI: realtime UPDATE clears resyncingAt
    end

Loading

_{Reviews (3): Last reviewed commit: "fix(OUT-3784): reject resync when one is..." | Re-trigger Greptile}

[greptile-apps]

Missing active-status guard on the channel

resyncFailedFilesForChannel looks up the channel by id + portalId + !deletedAt but never checks channel.status === true. A soft-inactive (status = false, deletedAt = null) channel passes this guard, so an authenticated portal member can POST to /api/sync/resync with the ID of any of their disabled channels and trigger a full bidirectionalMasterSync + tombstone retry on it — work that shouldn't run because the mapping has been deactivated. The UI hides the Resync button for inactive rows, but the API doesn't enforce the same constraint.

[greptile-apps]

concurrencyLimit: 1 on the queue may serialize all channels globally

The intent described in the PR is "different channels run in parallel; same channel serializes." That works when concurrencyKey is passed at trigger time AND trigger.dev applies concurrencyLimit per key — but the queue-level concurrencyLimit: 1 is a global limit for the whole named queue. If trigger.dev treats it globally (1 run across all keys at once), every second channel's resync would queue behind the first, serializing all channels regardless of which portal they belong to. Please confirm the per-key scoping behaviour in your trigger.dev version, or move the limit into the task's concurrency field with a key expression to make the per-channel intent explicit and version-proof.

[SandipBajracharya]

concurrencyLimit: 1 does not serialize all channels globally. Self verified.

[greptile-apps]

You're right, and I was wrong. In trigger.dev v3, concurrencyLimit on a queue applies per unique concurrencyKey, not globally. So concurrencyLimit: 1 + concurrencyKey: channelSyncId correctly means "1 concurrent run per channel" — different channels run in parallel as intended.

Apologies for the noise. The code is correct as written.

Tip: You can customize Greptile's behavior for this repo with .greptile/rules.md and .greptile/config.json.

[greptile-apps]

No recovery path if the trigger.dev worker is killed before finally executes

If the runner process is terminated by an OOM kill, a cold-start timeout, or a trigger.dev infrastructure event before the finally block runs, resyncing_at is never cleared. The channel row stays in "Resyncing…" state permanently — the UI button is disabled and the "Last Updated" cell shows "Resyncing..." with no way to clear it without a manual DB update. Consider adding a scheduled sweeper (e.g. clear resyncing_at where resyncing_at < NOW() - interval '30 minutes') to act as a watchdog, or expose an admin reset endpoint.

[SandipBajracharya]

Let this be for now. Low priority

[SandipBajracharya]

@greptileai

[greptile-apps]

resyncingAt goes dark for queued orchestrators

The channel lookup has no isNull(t.resyncingAt) guard. When a second request arrives while the first orchestrator is still running, both tombstone-reset and trigger proceed normally. The first orchestrator's finally block then clears resyncingAt — and the second orchestrator starts running with resyncingAt = null. From that point on the UI shows "Active", the Resync button is re-enabled, and the channel appears idle even though a full bidirectionalMasterSync is in progress. Adding isNull(t.resyncingAt) to the channel lookup (and returning a 409 Conflict) would cap this to one pending resync per channel, matching the invariant that "resyncingAt is set ↔ a resync is enqueued or running."

[SandipBajracharya]

@greptileai

[priosshrsth]

lgtm