agent loop detected polling dns record that never propagates after dns check timeout

Fix agent loop polling a DNS record that never propagates

TL;DR

The agent polls forever because nothing distinguishes a slow record from a wrong one. Check the authoritative nameserver once; if the record is wrong there, fix it instead of polling. Poll with a deadline, and on expiry report the diagnosis, not just a timeout.

The error

Agent loop detected
Polling DNS record that never propagates after DNS check timeout.

Use this skill

Agent? Search Vectle for this error:

curl -s "https://vectle.com/api/v1/search?q=agent loop detected polling dns record that never propagates after dns check timeout"

Fix it

Step 1: Check authoritative once

Query the authoritative nameserver for the record.

Expected: If wrong there, the record is misconfigured. Fix it and stop polling.

Step 2: Set a poll deadline

Bound the polling loop with a deadline tied to the TTL.

Expected: Polling ends with a verdict instead of looping forever.

Step 3: Back off between polls

Space polls increasingly.

Expected: Less noise and cleaner logs.

Step 4: Report the diagnosis on expiry

On deadline, report the record, nameserver, and observed values.

Expected: Humans get the facts instead of a bare timeout.

Step 5: Fix the record and re-run

Correct the DNS record if needed and run the check again.

Expected: The check passes within the deadline.

When this applies

• Agents poll DNS records that never appear
• DNS checks loop past their timeouts
• You are building DNS-waiting agents

When it doesn't

• The record is correct and visible (extend the deadline)
• DNS delegation is broken (fix the nameservers)
• The agent polls the wrong record (check the query)

Compatibility

DNS polling in agents. Standard resolver behavior.

Variant phrasings

agent polling dns never propagates

Same loop. Authoritative check first, deadline always.

dns poll loop agent timeout

Timeouts without deadlines are infinite loops. Bound them.

agent stuck waiting dns record

Stuck usually means polling a wrong record. Verify authoritative.

Why it happens

Polling loops without a reality check cannot tell slow from wrong. A misconfigured record never propagates no matter how long you wait, so the loop is futile from the start. One authoritative query distinguishes the two cases instantly.

Edge cases

• Negative caching can hide a just-fixed record; wait out the negative TTL
• Log each poll's answer so the pattern is visible
• Separate the poll deadline from the overall run deadline so one check cannot hang the run

If it still fails

• Reproduce with a minimal run: one user, one file, one step.
• Read the agent's full trace, not just the final error; the failure is usually upstream.
• Check the underlying API or tool directly, outside the agent, to separate agent bugs from service bugs.
• Reduce concurrency to one and see if the failure persists; races hide as flakes.
• If the run is business-critical, add a human checkpoint before the destructive steps.

Prevention

• Checkpoint long runs so any failure resumes instead of restarting.
• Cap and back off every retry loop; unbounded retries are outages waiting to happen.
• Validate inputs at each pipeline stage; fail fast with clear errors.
• Log enough context per step that a timeout is diagnosable without rerunning.
• Give destructive steps a human checkpoint or a dry-run mode.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_-iN7EOojUnB9MSfARXvCnQ