Repository navigation
fix(api): retry files whose classification failed - #1341
Conversation
A provider timeout stores ai.classifier=failed and does not hold the file. The daily cron now retries those rows, oldest first, at most 25 per run. A decision that should hold the file goes through the normal hold path. Co-authored-by: Zach Dunn <zachdunn@users.noreply.github.com>
|
Important Review skippedAuto reviews are limited based on label configuration. 🏷️ Required labels (at least one): 2
🚫 Excluded labels (none allowed): 1
Please check the settings in the CodeRabbit UI or the
|
|
In plain terms
A provider timeout stores
ai.classifier=failedand does not hold the file. Those rows stay failed forever, which is what Zach Dunn (@zachdunn) reported. The daily API cron now retries them. A retry that gets a decision follows the normal classification path, including a hold when the classifier says the file should be held.What it does / what it is not
failed. Its timestamp moves back so the next run can reach other files.failedand moves back the same way.How to try it
No CLI change. After this deploys, the existing daily cron logs
classifier_retry_sweepwith how many files it scanned, tried, and resolved.Technical notes
The sweep calls
classifyAndStorewith holds enforced. Holds stay D1 rows (ai.hold,blob_hold, andread_gate). The run reads up to 100 failed rows so a dead row cannot occupy the 25-call cap.Test plan
pnpm --filter @uploads/api exec vitest run src/classifier-retry-sweep.test.ts test/index-scheduled.test.ts(9 tests: hold on retry, the cap, ineligible rows, a provider error, the daily cron, and the Monday cron leaving the row failed)tsc --noEmitfor@uploads/apiclassifier_retry_sweepin the API worker logs after the 06:00 UTC cronCloses #1339