OUT-3804: reconcile early-stamped assemblyFileId on create retry by SandipBajracharya · Pull Request #110 · assemblycom/dropbox-integration

SandipBajracharya · 2026-06-01T07:50:48Z

What

retryCreateInAssembly now reconciles a row's early-stamped assemblyFileId before re-creating, so a sweeper retry can't orphan the existing Assembly file or produce a duplicate.

Branches on the existing Assembly file's state:

State	Action
`completed`	mark row synced + bump count, no re-create
pending & < 1 day old	wait, retry next sweep
pending & ≥ 1 day old	null the id → delete the file → re-create
404	re-create

Refactor

Extracted the inline block into reconcileExistingAssemblyFile (returns a "should re-create" boolean).
Hoisted the magic timeout to STUCK_PENDING_THRESHOLD_MS.
De-duplicated the three identical channelSync lookups into getChannelSync.

Race safety

The stale-reclaim path nulls assemblyFileId before the API delete, so the resulting file.deleted webhook can't match this row and race the re-create. A unit test pins this ordering via invocationCallOrder.

Tests

New resync-failed-files.helper.test.ts covers all reconcile branches (completed / pending-young / pending-stale / 404 / no-id / source-gone). The 404 test throws a properly-shaped CopilotApiError and uses the real guard logic, so it actually exercises the production isCopilotApiError check.

pnpm typecheck, pnpm lint, and the resync + tombstone vitest suites all pass.

Related: OUT-3645

🤖 Generated with Claude Code

retryCreateInAssembly now checks the existing Assembly file before re-creating, so a retry can't orphan it or produce a duplicate: completed -> mark synced; pending & young -> wait; pending & stale -> null id, delete, re-create; 404 -> re-create. Extracted the block into reconcileExistingAssemblyFile, hoisted STUCK_PENDING_THRESHOLD_MS, and shared the channelSync lookup. Added unit tests for each branch. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

linear-code · 2026-06-01T07:50:51Z

OUT-3804

vercel · 2026-06-01T07:50:54Z

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

Project	Deployment	Actions	Updated (UTC)
dropbox-integration	Ready	Preview, Comment	Jun 1, 2026 11:26am

greptile-apps · 2026-06-01T07:53:44Z

Greptile Summary

This PR fixes a sweeper retry bug where an early-stamped assemblyFileId could cause duplicate Assembly files or orphaned uploads. It introduces reconcileExistingAssemblyFile to branch on the existing file's state before deciding whether to re-create, and adds getChannelSync to de-duplicate three identical DB lookups.

Reconcile logic: four branches — already-completed (mark synced, no re-create), pending-young (wait), pending-stale (null id → delete → re-create), 404 (re-create directly). The null-before-delete ordering prevents a file.deleted webhook from racing the re-create.
Race safety: assemblyFileId is nulled in the DB before calling deleteFile, so a concurrent webhook handler can't match the row during deletion. A unit test pins this ordering via invocationCallOrder.
Test coverage: new resync-failed-files.helper.test.ts exercises all six reconcile branches including a properly-shaped CopilotApiError for the 404 path.

Confidence Score: 3/5

Safe to merge for the common cases, but the age-gate in reconcileExistingAssemblyFile silently swallows any non-completed, non-pending Assembly file status — worth confirming the API's full status surface before landing.

The reconcile logic only explicitly handles completed and, implicitly, pending. Any other status the Assembly API might return (e.g. failed, error) falls through to the 24-hour age-gate: young files get a misleading 'still pending' retry message and re-creation is delayed by up to a day, while only stale ones are correctly deleted and re-created. If the Assembly API's file status is strictly binary (completed | pending), this is a non-issue; but if other statuses are possible, the retry loop silently misclassifies them.

src/features/workers/resync-failed-files/helper/resync-failed-files.helper.ts — specifically the reconcileExistingAssemblyFile function's post-completed fallthrough.

Important Files Changed

Filename	Overview
src/features/workers/resync-failed-files/helper/resync-failed-files.helper.ts	Adds reconcileExistingAssemblyFile to handle early-stamped assemblyFileId on create retries; logic gap: non-pending/non-completed statuses fall through to the age-gate and trigger misleading markFailure or spurious delete.
src/features/workers/resync-failed-files/helper/tests/resync-failed-files.helper.test.ts	New test file covering all described reconcile branches (completed, pending-young, pending-stale, 404, no-id, source-gone); no test for unexpected/non-pending Assembly file statuses, which is where the logic gap in the helper lives.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[retryCreateInAssembly] --> B{dbxFileId / itemPath / channelSync present?}
    B -- No --> Z[markFailure / markDeleted]
    B -- Yes --> C{Dropbox file exists?}
    C -- No / deleted --> D[markDeleted]
    C -- Yes --> E[reconcileExistingAssemblyFile]

    E --> F{assemblyFileId present?}
    F -- No --> G[return true]
    F -- Yes --> H[retrieveFile]

    H -- completed --> I[markUpdated + updateChannelMapSyncedFilesCount
return false]
    H -- other status --> J{row age < 24h?}
    J -- Yes --> K[markFailure 'still pending'
return false]
    J -- No --> L[updateFileMap assemblyFileId=null
deleteFile
return true]
    H -- 404 --> G

    G --> M[completePendingAssemblyCreate]

_{Reviews (1): Last reviewed commit: "fix(OUT-3804): reconcile early-stamped a..." | Re-trigger Greptile}

priosshrsth · 2026-06-01T08:41:00Z

+    })
+    return true
+  } catch (error) {
+    if (!isCopilotApiError(error) || error.status !== 404) {


Should this be || or &&?

My understanding is if 404, then it means file does not exist, right? But I think that should go to .catch in line 274.

It's ||. This basically means if the error is not related to copilotError or the request responded with 404 not found we assume the file is not available and we return true.

Will update this try catch block. Thanks for the suggestion

priosshrsth · 2026-06-01T08:43:33Z

+  if (!failedSync.assemblyFileId) return true
+
+  try {
+    const existing = await copilotApi.retrieveFile(failedSync.assemblyFileId)


Better to return true early, if existing is not defined, etc.

Suggested change

const existing = await copilotApi.retrieveFile(failedSync.assemblyFileId)

const existing = await copilotApi.retrieveFile(failedSync.assemblyFileId).catch((e: AxiosError) => es.status == 404 ? null : throw e)

if (!existing) return true

Will update this try catch block. Thanks for the suggestion.

priosshrsth · 2026-06-01T08:44:54Z

+        'retryCreateInAssembly: Assembly file still pending upload, will retry next sweep',
+      )
+      return false
+    }


Should it be retried though? If upload is in progress and this request did not intiate it, then retry would be processed by the original request that initiated the upload, wouldn't it?

Yes it should be retried. The original request retry for 3 attempts and if the attempt still fails (due to uploads failure), the status is always on pending. We retry and check if status is pending for more than a day. If so we delete that pending record from assembly and create new one and upload again.

Resolve the early-stamped assemblyFileId 404 case at the retrieveFile call so a missing file routes to the create path, while non-404 Copilot errors propagate for retry instead of being swallowed. Removes the now pass-through try/catch. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

priosshrsth

lgtm

vercel Bot deployed to Preview June 1, 2026 07:51 View deployment

SandipBajracharya changed the title ~~fix(OUT-3804): reconcile early-stamped assemblyFileId on create retry~~ OUT-3804: reconcile early-stamped assemblyFileId on create retry Jun 1, 2026

greptile-apps Bot reviewed Jun 1, 2026

View reviewed changes

Comment thread src/features/workers/resync-failed-files/helper/resync-failed-files.helper.ts Outdated

priosshrsth requested changes Jun 1, 2026

View reviewed changes

vercel Bot deployed to Preview June 1, 2026 11:26 View deployment

priosshrsth approved these changes Jun 1, 2026

View reviewed changes

SandipBajracharya merged commit 07d0c01 into main Jun 1, 2026
4 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

OUT-3804: reconcile early-stamped assemblyFileId on create retry#110

OUT-3804: reconcile early-stamped assemblyFileId on create retry#110
SandipBajracharya merged 2 commits into
mainfrom
OUT-3804

SandipBajracharya commented Jun 1, 2026

Uh oh!

linear-code Bot commented Jun 1, 2026

Uh oh!

vercel Bot commented Jun 1, 2026 •

edited

Loading

Uh oh!

greptile-apps Bot commented Jun 1, 2026

Uh oh!

Uh oh!

priosshrsth Jun 1, 2026

Uh oh!

SandipBajracharya Jun 1, 2026

Uh oh!

priosshrsth Jun 1, 2026

Uh oh!

SandipBajracharya Jun 1, 2026

Uh oh!

priosshrsth Jun 1, 2026

Uh oh!

SandipBajracharya Jun 1, 2026 •

edited

Loading

Uh oh!

priosshrsth left a comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

-    const existing = await copilotApi.retrieveFile(failedSync.assemblyFileId)
+    const existing = await copilotApi.retrieveFile(failedSync.assemblyFileId).catch((e: AxiosError) => es.status == 404 ? null : throw e)
+    if (!existing) return true

Conversation

SandipBajracharya commented Jun 1, 2026

What

Refactor

Race safety

Tests

Uh oh!

linear-code Bot commented Jun 1, 2026

Uh oh!

vercel Bot commented Jun 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

greptile-apps Bot commented Jun 1, 2026

Greptile Summary

Confidence Score: 3/5

Important Files Changed

Flowchart

Uh oh!

Uh oh!

priosshrsth Jun 1, 2026

Choose a reason for hiding this comment

Uh oh!

SandipBajracharya Jun 1, 2026

Choose a reason for hiding this comment

Uh oh!

priosshrsth Jun 1, 2026

Choose a reason for hiding this comment

Uh oh!

SandipBajracharya Jun 1, 2026

Choose a reason for hiding this comment

Uh oh!

priosshrsth Jun 1, 2026

Choose a reason for hiding this comment

Uh oh!

SandipBajracharya Jun 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

priosshrsth left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

vercel Bot commented Jun 1, 2026 •

edited

Loading

SandipBajracharya Jun 1, 2026 •

edited

Loading