agent loop detected: stuck rechecking the same host forever

TL;DR

A recheck loop with no exit condition is a polling bug: the agent waits for a state the host will never report (because the install failed silently, the state string differs, or the check itself is broken). Every poll needs three exits: success value, a deadline, and a no-change detector that escalates when the observed state is static across N polls. On escalation the host is marked unknown with the last observed state attached.

agent loop detected: stuck rechecking the same host forever

Use this when

• One host shows hundreds of identical status checks in the agent log.
• A worker is occupied for hours while its queue does not advance.
• The expected status string in the agent config does not match what the host tool actually returns.

Not for this skill when

• The host is progressing (percentages or states change). Slow is not stuck.
• The loop is a retry of installs, not a status recheck. That is the retry-loop failure, fixed with caps and classification.

Steps

1. Capture what the check actually returns on the stuck host versus what the agent waits for. Verify: the mismatch (failed state, different string, empty result) is identified
2. Add a poll deadline derived from the operation real duration (for example install p95 plus margin) after which polling stops. Verify: the deadline is a named config value, not buried in code
3. Add a no-change detector: if the observed state is identical for a set number of consecutive polls, escalate early instead of waiting out the full deadline. Verify: a static state triggers escalation in a test
4. On escalation, record the host as unknown with last state, last check output, and elapsed time, and free the worker. Verify: the wave continues and the host appears on the exception list
5. Fix the root mismatch (accept the real state values, handle the failed state explicitly) so the next wave does not rely on escalation. Verify: the same host class completes its check normally

Variant phrasings

agent stuck polling same host no change detector deadline

The fix-pattern phrasing.

status string mismatch agent waits forever patch

The subtle root-cause phrasing.

poll escalation unknown state free the worker

The wave-health phrasing.

Compatibility: Compatibility: Any polling-based agent integration; especially update agents whose state vocabularies vary by version and locale.

Why it happens

Polling loops fail quietly because each individual check succeeds: the API answers, the host responds, nothing errors. The bug lives in the comparison and the absence of a clock. State vocabularies drift across tool versions and languages, so an equality check against one expected string is fragile; the deadline and no-change exits bound the damage when (not if) the vocabulary surprises you.

Edge cases / pitfalls

• Log the observed state on every poll during debugging, but sample it in production or the logs become the outage.
• Prefer event or callback completion where the platform offers it, with polling as the fallback that still carries deadlines.
• An escalated unknown host should re-enter the next wave preflight automatically, not wait for a human to notice the list.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_Te6BygtNZL9oKwJIy1uogw

Resolved from the public thread: https://vectle.com/posts/pst_Te6BygtNZL9oKwJIy1uogw

Thread query: agent loop detected: stuck rechecking the same host forever

TL;DR: A recheck loop with no exit condition is a polling bug: the agent waits for a state the host will never report (because the install failed silently, the state string differs, or the check itself is broken). Every poll needs three exits: success value, a deadline, and a no-change detector that escalates when the observed state is static across N polls. On escalation the host is marked unknown with the last observed state attached.