Repository navigation
OUT-4175: tighten stuck-pending threshold and retry sweep cadence - #152
Conversation
Reduce STUCK_PENDING_THRESHOLD_MS from 12h to 2h and run the retry sweep three times a day (every 8h) instead of twice. Update the young stuck-pending test to seed under the new 2h cut-off. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
 |
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
Seed the abandoned stuck-pending rows just over the new 2h cut-off (hoursAgo(3)) so a regression back to the old 12h threshold fails the test. Addresses Greptile review. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
@greptileai review again |
SandipBajracharya
changed the title
Give slow in-flight Assembly uploads more time before the sweep treats them as abandoned and force deletes + recreates them. Move the pinned abandoned-reclaim fixtures just past the new cut-off. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
@greptileai review |
| // Pending uploads older than 4 hours are treated as abandoned and reclaimed. | ||
| const STUCK_PENDING_THRESHOLD_MS = 4 * 60 * 60 * 1000 |
There was a problem hiding this comment.
The latest revision sets the stale-upload cutoff to 4 hours instead of the intended 2 hours. A pending Assembly upload between 2 and 4 hours old will therefore remain untouched in both scheduled and manual recovery, delaying resynchronization. The integration fixtures were also changed from 3 to 5 hours, so they now enforce the unintended 4-hour cutoff.
| // Pending uploads older than 4 hours are treated as abandoned and reclaimed. | |
| const STUCK_PENDING_THRESHOLD_MS = 4 * 60 * 60 * 1000 | |
| // Pending uploads older than 2 hours are treated as abandoned and reclaimed. | |
| const STUCK_PENDING_THRESHOLD_MS = 2 * 60 * 60 * 1000 |
Knowledge Base Used: Failed-file resynchronization
There was a problem hiding this comment.
Change to 4h is intentional as there can be certain reason for slow upload of the file in Assembly (trigger.dev issue, large files, etc). This is done to be on the safe side.
There was a problem hiding this comment.
That makes sense. Given the possibility of slow Assembly uploads from Trigger.dev issues or large files, the 4-hour cutoff is an intentional safety margin. With that context, my concern about the 2-hour requirement does not apply, so I’m withdrawing this review comment.
Summary
Tunes two loose values in the failed-sync resync path (OUT-4175).
STUCK_PENDING_THRESHOLD_MSfrom 12h → 2h — the grace period before a still-pendingAssembly file is treated as abandoned and reclaimed (delete + re-create). Normal uploads complete in seconds–minutes, so 2h is ample headroom while reclaiming genuinely stuck files far sooner.0 0,8,16 * * *) instead of twice a day.Notes
MAX_ATTEMPTSexhaustion from ~5 days to ~3.3 days (intended).Testing
pnpm typecheck— cleanpnpm test(unit) — 294 passedpnpm test:integration) needs a container runtime and was not run in this environment.🤖 Generated with Claude Code