the scanner webhook never arrived - the agent sat idle for 6 hours waiting on a scan-complete event that was already...
Fixes a CVE triage agent stuck waiting on a scanner webhook that never arrives even though the scan finished. Use it when the agent sits idle for hours on a scan-complete event the scanner already completed. Key trigger: the scanner dashboard shows the scan done but the agent's webhook receiver has no record of the event.
TL;DR: Stop waiting on the webhook alone and poll the scanner's scan-status API with a deadline. Webhooks get lost to rotated receiver URLs, signature-verification failures, or proxy blocks, and the agent cannot tell "scan still running" apart from "event lost". A poller with a timeout converts a silent 6-hour stall into a bounded wait plus an alert.
agent log: waiting for scan-complete webhook (6h elapsed) - scanner shows scan finished 5h ago- Look up the scan in the scanner UI or API and confirm it completed and when. Expected: you confirm the scan finished, so the missing piece is delivery, not the scan itself.
- Check the webhook receiver logs for rejected deliveries around the completion time. Expected: you find a signature failure, a 404 on the endpoint, or nothing at all (the event was never sent).
- Verify the registered webhook URL is still correct and reachable from the scanner's network - most scanners have a test-delivery button in the webhook settings. Expected: a test delivery returns 200.
- Add a poller: every 5 minutes query the scan-status API, and proceed when the status reads complete or a 30-minute deadline passes. Expected: the agent advances on the next poll even if the webhook never arrives.
- Keep the webhook as the fast path but make event handling idempotent. Expected: a late duplicate delivery does not re-trigger triage.
Use this when
- the agent waits on scan-complete webhooks that never arrive
- scans finish but the agent never wakes up
- the webhook receiver shows delivery gaps
- pipeline stalls with no error, just silence
Not for this skill when
- the scan itself never finishes (a scanner performance problem)
- the webhook arrives but the payload fails to parse (a parser problem)
- you control neither the scanner nor the receiver
- the event is delayed minutes, not lost for hours
Variant phrasings
- scanner webhook not delivered to agent
- agent stuck waiting for scan event
- webhook lost, triage pipeline stalled
- scan-complete event never received
Why it happens
Webhooks are fire-and-forget: endpoint URL rotations, expired signing secrets, proxy or firewall changes, and receiver restarts during delivery all drop events silently. The agent's wait has no deadline, so a lost event looks identical to a slow scan - until someone notices the idle hours.
Edge cases
- scanners often retry webhooks with backoff, so the poller must be idempotent against a late webhook arriving after the poll already advanced the pipeline
- clock skew between scanner and agent shifts "completed at" comparisons - compare statuses, not timestamps
- some scanners only send webhooks for scheduled scans, not manual or API-triggered ones - the poller covers both
- a deadline that is too short pages on genuinely long scans - base it on the 99th percentile scan duration
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_kd1BGBq0nDaPkkkFmD3Upw