[deanrie]

What

moderation.rescanPlugin now refuses while a scan for the plugin is already queued or running, and the MCP rescan_plugin tool relies on that instead of its own copy of the check.

Why

Two entry points queue an admin re-scan. The MCP tool checks the row first and refuses while scan_status is pending/scanning with updated_at younger than 15 minutes (its description promises exactly that). The web action rescanPluginAction, behind the Re-scan buttons on the Stuck tab, the flagged review list and the plugin admin panel, calls rescanPlugin directly, which sets pending and sends a queue message unconditionally.

So a click while the first scan is still queued (waiting for the one-minute drain, or invisible under the 900 s visibility timeout) or running puts a second message for the same plugin into plugin_scans. Each message becomes a full runPluginScan, that is a second billable agent run, and the two applyVerdict writes race. The admin panel shows a spinner for pending/scanning but keeps the button enabled; disabled={busy} only covers the button's own request.

Change

• moderation.ts: SCAN_IN_PROGRESS_MS (15 min, the same threshold getStuckScans and the recover cron use) and isScanInProgress(state); rescanPlugin loads the row and throws ModerationError before the status write. Rows older than 15 minutes are still re-scannable, since that is the definition of stuck everywhere else.
• lib/mcp/tools.ts: rescan_plugin drops the private constant and check and calls rescanPlugin with the resolved id. adminTool already returns ModerationError as the tool error text, so the tool's reply is unchanged.

The web action needs no edit: safe-action.ts already surfaces ModerationError as the toast text.

Checked

• Probe with the real moderation.ts and a stub Supabase that bumps updated_at on update like the plugins_set_updated_at trigger. On main: pending 1 min old, scanning 2 min old, and an error row clicked three times all enqueue (3 messages for the three clicks). With this change: fresh pending/scanning refused with the MCP wording, three clicks give 1 message, pending/scanning older than 15 min still enqueue, safe/flagged/error/unscanned unchanged. Run twice.
• tsc --noEmit clean, biome clean.
• git merge-tree clean against main and against fix(plugins): fail delete when no row was removed; render logos unoptimized #449, fix(plugins): install repo-ingested MCP servers under their submitted name and show a paste-ready config (lands #427; closes #416) #457, plugins: let owners re-run the security scan from the listing menu #458, 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. plugins: let owners re-run the security scan from the listing menu #458 (owner re-scan) keeps its stricter own check and is unaffected.

The check is read-then-write, so two requests inside the same few milliseconds can still both pass; the button busy state covers that at human speed. A drain-side skip of messages older than the plugin's last_scanned_at would close the remaining window and the equal VT_SECONDS / STALE_AFTER_MS case in the recover cron; left for a separate change.

[vercel]

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

A member of the Team first needs to authorize it.