OUT-3782: prevent Dropbox↔Assembly ping-pong on file create

[SandipBajracharya]

Summary

Closes a race where a Dropbox→Assembly create can echo back via Assembly's file.created webhook and produce duplicate files on both sides. Stacks on top of OUT-3645 (#106).

What's in this PR

1. Early-stamp assemblyFileId — Sync.service.ts#completePendingAssemblyCreate
Persists assemblyFileId via updateFileMap immediately after copilotApi.createFile() returns, before the (potentially seconds-long) S3 upload. Shrinks the race window from the upload duration to a single UPDATE roundtrip, so the Assembly webhook controller's 800ms sleep + existingFile lookup actually catches the echo.

2. itemPath-based dedupe in the Assembly webhook controller — webhook.controller.ts
Adds a second lookup on file_folder_sync matching (portalId, normalized itemPath, pendingAction = CREATE, pendingActionTarget = ASSEMBLY, deletedAt IS NULL). Catches the residual race where Assembly fires file.created before our createFile HTTP response returns — at that point we haven't stamped assemblyFileId, but the pre-inserted tombstone row already has the itemPath populated, so we can still match. Stored itemPath has a leading /; Copilot's data.path doesn't, so the lookup normalizes.

3. Handler ordering swap — processFileSync.ts#handleChannelFileChanges
Process deletes before creates. With the partial unique indexes from OUT-3778, a rename flow can otherwise hit there is no unique or exclusion constraint matching the ON CONFLICT specification if the new path's create races the old path's delete.

Why the ping-pong happens

1. copilotApi.createFile     → Assembly creates file, fires file.created (~100ms)
2. uploadFileInAssembly      → S3 upload (seconds for large files)
3. markUpdated(assemblyFileId)  ← old code only stamped here

If the Assembly echo arrives between (1) and (3), our existing dedupe (which keys off assemblyFileId) misses → we trigger syncAssemblyFileToDropbox → duplicate appears in Dropbox → loop.

Test plan

• pnpm typecheck clean
• pnpm lint clean
• pnpm test passes
• Manual: upload a file to Dropbox, verify exactly one copy appears in Assembly (and stays at one — no echo).
• Manual: upload a large file (>10 MB so upload takes seconds), verify no duplicate is created during the upload window.
• Manual: rename a file in Dropbox, verify the delete + create sequence applies cleanly without ON CONFLICT errors on the partial unique indexes.

🤖 Generated with Claude Code

[linear-code]

OUT-3782

[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:56am

[greptile-apps]

Greptile Summary

This PR closes the Dropbox↔Assembly ping-pong race by deploying three coordinated fixes: an early assemblyFileId stamp in completePendingAssemblyCreate (before the S3 upload), a path-based in-flight dedupe lookup in the webhook controller, and a delete-before-create ordering swap to prevent partial unique index violations on renames.

• Early stamp (Sync.service.ts): updateFileMap writes assemblyFileId immediately after copilotApi.createFile() returns, shrinking the race window from "entire upload duration" to one DB round-trip so the controller's existingFile lookup can catch the echo.
• Path-based dedupe (webhook.controller.ts + webhook.service.ts): findInFlightAssemblyCreate covers the residual sub-round-trip window by matching the pre-inserted tombstone row on (portalId, channelSyncId, itemPath, pendingAction=CREATE, assemblyFileId IS NULL), correctly scoped per channel via a two-query pattern.
• Order swap (processFileSync.ts): Processes deletes before creates to avoid ON CONFLICT errors on partial unique indexes during rename flows.

Confidence Score: 4/5

Safe to merge; all three previously raised issues are addressed and the dedupe logic correctly covers both the post-stamp and pre-stamp windows.

The three-layered race fix (early stamp + path-based lookup + delete-before-create ordering) is sound and all previous thread concerns have been resolved. The only new gap is observability: when pendingCreate suppresses a create event, nothing is logged, which would make it hard to confirm the dedupe is firing correctly in production. The core logic is correct.

webhook.controller.ts — the suppression branch at line 71 has no log emit; worth a one-liner before shipping to production.

Important Files Changed

Filename	Overview
src/features/sync/lib/Sync.service.ts	Early-stamps assemblyFileId via updateFileMap immediately after copilotApi.createFile() returns, before the S3 upload. Shrinks the race window to a single DB round-trip so the controller's existingFile lookup can catch the echo.
src/features/webhook/assembly/api/webhook.controller.ts	Adds isCreateEvent guard and calls findInFlightAssemblyCreate only for create events. Guards handleFileCreated with both existingFile and pendingCreate checks. No log on suppression path is the only minor gap.
src/features/webhook/assembly/lib/webhook.service.ts	New findInFlightAssemblyCreate correctly scopes to (portalId, channelSyncId, itemPath, pendingAction=CREATE, pendingActionTarget=ASSEMBLY, assemblyFileId IS NULL, deletedAt IS NULL) via a two-query pattern that addresses the previous cross-channel false-positive concern.
src/trigger/processFileSync.ts	Swaps batch-trigger order from create-then-delete to delete-then-create to prevent ON CONFLICT errors on partial unique indexes during rename flows.

Sequence Diagram

sequenceDiagram
    participant DBX as Dropbox
    participant Sync as SyncService
    participant DB as Database
    participant ASM as Assembly API
    participant WH as Webhook Controller

    DBX->>Sync: file change detected
    Sync->>DB: "pre-insert row (pendingAction=CREATE, assemblyFileId=NULL)"
    Sync->>ASM: copilotApi.createFile()
    ASM-->>Sync: "fileCreateResponse (id=X)"
    Sync->>DB: "updateFileMap(assemblyFileId=X) ← early stamp"
    ASM->>WH: "file.created echo (data.id=X) ~100ms later"
    WH->>WH: sleep(800ms)
    WH->>DB: "existingFile lookup (assemblyFileId=X)"
    DB-->>WH: row found → skip handleFileCreated ✓
    Sync->>ASM: uploadFileInAssembly (S3, seconds)
    Sync->>DB: "markUpdated(assemblyFileId=X, pendingAction=null)"

    note over WH,DB: Residual window: stamp not yet committed
    ASM->>WH: file.created echo arrives before stamp
    WH->>DB: existingFile lookup → null
    WH->>DB: findInFlightAssemblyCreate(channelId, path)
    DB-->>WH: pre-insert row matched (assemblyFileId IS NULL) → skip ✓

Loading

_{Reviews (3): Last reviewed commit: "fix(OUT-3782): scope in-flight dedupe to..." | Re-trigger Greptile}

[SandipBajracharya]

@greptileai

[SandipBajracharya]

@greptileai

[priosshrsth]

lgtm