[deanrie]

What

recover-stuck-scans resets a stale scanning row to pending without enqueueing it again. Stale pending rows are enqueued as before.

Why

The drain archives a queue message only after runPluginScan has written a terminal status: applyVerdict on success, markScanFailed on fatal, retryable and MAX_ATTEMPTS paths, applyBlockedShortCircuit for blocked plugins. The one way a row stays at scanning past the threshold is a worker that died mid-run (800 s cap, OOM, platform kill). That worker never archived its message, so the message comes back when the 900 s visibility timeout expires and the minute drain re-reads it.

The cron already handles that row by resetting it to pending, and then also calls enqueuePluginScan. That puts a second message for the same plugin into plugin_scans: two full runPluginScan calls (two billable agent runs) and two applyVerdict writes racing. With VT_SECONDS (900) equal to STALE_AFTER_MS (15 min) the returning message and the cron's duplicate arrive within the same minute.

pending is different: insert, update and re-scan all catch an enqueuePluginScan failure and leave the row at pending for this cron to pick up (see the comment in insert.ts), so a stale pending row may have no message at all and re-enqueueing it is the cron's job.

Change

One file. A stale scanning row is reset and reported as action: "reset"; a stale pending row is enqueued and reported as action: "enqueued". The response adds a reset count next to retried and failed. If a reset row's message really is gone (a row from before the queue existed), the next tick sees it as stale pending and enqueues it then, so recovery moves by one tick rather than being lost.

Checked

• Probe with the real route.ts and a stub Supabase + queue: on main one tick over a 16 min old scanning row and a 16 min old pending row enqueues both; with this change it resets the first and enqueues the second, and a second tick 16 min later enqueues the reset row if nothing drained it. Fresh pending/scanning, error and safe rows untouched in both.
• biome clean. tsc reports the same single pre-existing error in scan.ts (platform on AgentOptions) on main and on this branch.
• git merge-tree clean against main and against plugins: let owners re-run the security scan from the listing menu #458, fix(scan): cap what a repository archive unpacks to before it reaches tmpfs #469, fix(admin): judge a stuck scan by updated_at, like the recovery cron and the rescan tool #470, fix(github-plugin): encode repo paths in raw.githubusercontent.com URLs #472, fix(moderation): refuse a re-scan while one is queued or running, from every entry point #473.

Related: #473 removes the same duplicate from the admin re-scan buttons. Not covered here: a worker killed between applyVerdict and archivePluginScan still re-runs once when its message returns, and a stale pending row whose message is merely waiting in a backlog still gets a duplicate; both need either a scan start timestamp on the row or queue introspection.

[vercel]

@deanrie is attempting to deploy a commit to the Anysphere Team on Vercel.

A member of the Team first needs to authorize it.