agent re-scans the same authorized target after every timeout instead of skipping it
Teaches an agent to quarantine flaky authorized targets instead of re-scanning them after every timeout. Use when the agent burns its time budget re-hitting the same timing-out host. Not for one-off timeouts on otherwise healthy targets.
TL;DR
The agent re-scans because a timeout leaves no record, so the target looks fresh every time. Give each target a failure budget of two timeouts, then quarantine it for the rest of the run and spend the time on unscanned targets instead.
(agent re-scans TARGET after each timeout; same timeout repeats)Use this when
- The agent log shows the same authorized target timing out across multiple scan types, each followed by another attempt.
- The run is spending more time on one flaky host than on the rest of the scope.
Not for this skill when
- Timeouts are spread across many targets. That is a network or rate problem, not a per-target loop.
- The target just needs a longer timeout once. A single adjustment is tuning, not quarantine.
Steps
- Count the timeouts per target in the run log. Verify: one target accounts for a disproportionate share of attempts.
- Quarantine it: mark the target skipped-for-now with the timeout evidence attached. Verify: the planner's next-target selection excludes it.
- Continue the run across the remaining scope. Verify: overall progress resumes instead of stalling on the flaky host.
- At the end of the run, make one deliberate retry of quarantined targets with a longer timeout and a narrower scan. Verify: the retry is a single planned attempt, not the loop restarting.
- Report quarantined targets as "unscannable within time budget" with the timeout logs attached. Verify: the report is honest about the gap instead of silent.
Variant phrasings
agent keeps retrying timed out target
The budget-burning phrasing.
flaky target stalls agent scan run
The symptom phrasing.
agent timeout retry storm one host
The rate-shaped phrasing.
Compatibility: harness scheduling fix; tool-agnostic.
Why it happens
Timeouts are the least informative failure: no output, no error, just silence. Planners that treat "no result" as "not attempted" will keep attempting, and a host that times out once usually times out the same way ten times.
Edge cases / pitfalls
- Quarantine is per-run, not permanent. A target that was down during the scan window may be up for the retest; the next run starts fresh.
- Do not quarantine a target the engagement specifically prioritizes without telling the test lead. Priority targets get manual attention, not silent skipping.
- If most targets time out, the problem is the tester box or the network path. Quarantining everything is a signal to stop and diagnose.
- The end-of-run retry should use a longer timeout than the attempts that failed; retrying with the same timeout just re-proves the timeout.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst_rKPEKKx6yZx16WGpp7kfMQ