agent loop detected: agent polls airbyte job status forever after job cancelled error

Not specified by the original author.

TL;DR

Stop polling a terminal state: the Airbyte job was cancelled, and cancelled is final, so read the job status once, treat cancelled and failed as terminal in the polling logic, and exit with the job outcome instead of waiting for a success that cannot come. The agent waits because its poll loop only recognises success and running states. A cancelled job sits outside that list forever.

agent loop detected: agent polls airbyte job status forever after job cancelled error

Use this when

• The check or run fails with this symptom: an agent loop polls Airbyte job status forever after the job is cancelled.
• You are working on an agent workflow that starts Airbyte syncs and waits for completion and the failure repeats on the same data or configuration.
• You need the failing rows, rule, or stage isolated before changing thresholds or code.

Not for this skill when

• A job stuck in running with a live worker, where the issue is a hung sync rather than a missed terminal state.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Fetch the job status directly and confirm its current state. Verify: the job is in a terminal cancelled state
2. List the states the polling loop treats as final. Verify: cancelled is missing from the terminal set
3. Add cancelled, failed, and incomplete to the terminal set, with the job outcome reported on exit. Verify: a test poll against the cancelled job exits immediately
4. Add a maximum poll duration as a backstop for unknown states. Verify: the loop cannot run past the cap
5. Record the cancelled outcome in the run summary with the job id. Verify: the cancellation is visible instead of a timeout

Variant phrasings

agent polls airbyte job status forever job cancelled

The shorter phrasing focused on the named failure.

airbyte job cancelled agent loop polling error

The symptom phrasing a searcher tries next.

airbyte polling terminal states fix

The variant naming the failing stage or tool directly.

Compatibility: Airbyte jobs API and agent polling workflows

Why it happens

Airbyte jobs end in several states beyond succeeded, including cancelled by a user or by a workspace action. Poll loops written against the happy path wait indefinitely on those states, and the agent appears hung while the platform finished long ago.

Edge cases / pitfalls

• A job cancelled from the UI gives no error detail; report it as cancelled by an external action, not as a sync failure.
• Poll with backoff and a cap even for running jobs; a fixed short interval against the jobs API invites rate limits.

Provenance

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

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

Thread query: agent loop detected: agent polls airbyte job status forever after job cancelled error

TL;DR: Stop polling a terminal state: the Airbyte job was cancelled, and cancelled is final, so read the job status once, treat cancelled and failed as terminal in the polling logic, and exit with the job outcome instead of waiting for a success that cannot come. The agent waits because its poll loop only recognises success and running states. A cancelled job sits outside that list forever.

Not specified by the original author.

TL;DR

The agent is polling a sync whose state has not changed, which means the sync is stuck and more polls will not unstick it. Cap the checks at a small number of unchanged responses, then pivot: read the sync phase from history once, and escalate the stuck sync with the phase named. The loop is the agent waiting for a state change that is not coming.

agent loop detected: retrying fivetran sync status check, sync stuck

Use this when

• An agent re-checks Fivetran sync status repeatedly with no state change.
• The check count grows while the sync state stays fixed.
• The agent's task cannot proceed until the sync finishes.

Not for this skill when

• The sync is progressing between checks. That is polling, not a loop.
• One status check failed. Retry the check, not the strategy.

Steps

1. Count consecutive unchanged status responses. Note the count. Verify: the loop is measured, not felt
2. After the unchanged threshold, stop polling and read the sync history once for the stuck phase. Note the phase. Verify: the investigation pivots
3. Decide: bounded wait for a slow phase, or escalate the stuck sync. Note the decision. Verify: the agent chooses instead of looping
4. Escalate with connector, phase, and stall duration. Note the escalation. Verify: a human gets an actionable report
5. Record the loop signature so the next run recognizes it earlier. Note the record. Verify: the pattern is learned

Variant phrasings

agent polling loop fivetran

The agent-shaped search.

break out of status check loop

The fix phrasing.

Compatibility: Fivetran API and dashboard for sync state. Loop-breaking is an agent behavior pattern.

Why it happens

Polling loops form when the agent's plan has exactly one next step, check again, and no rule for giving up. Each unchanged response should reduce the expected value of the next check, but agents without a loop detector treat every check as fresh hope. The unchanged-response counter is the simplest loop detector there is: it turns I have checked many times into the state has not changed N times, which is actionable. Stuck external systems do not respond to being watched.

Edge cases / pitfalls

• A sync that progresses slowly between checks is not a loop. Only unchanged states count toward the threshold.
• Escalating without the phase and stall duration just moves the loop to a human. Include the evidence.
• Some agents loop because their task has no alternative path. Give the agent a real fallback: proceed without the sync or abort cleanly.
• Log loop detections as events. Repeated loop signatures across runs indicate a missing capability, not a flaky sync.

Provenance

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

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

Thread query: agent loop detected: retrying fivetran sync status check, sync stuck

TL;DR: The agent is polling a sync whose state has not changed, which means the sync is stuck and more polls will not unstick it. Cap the checks at a small number of unchanged responses, then pivot: read the sync phase from history once, and escalate the stuck sync with the phase named. The loop is the agent waiting for a state change that is not coming.

Not specified by the original author.

TL;DR

The agent fires a BigQuery job and blocks on it with a short timeout instead of polling the job state properly. Fix it by submitting the job, then polling job.result() with a generous timeout in a loop (or using BigQuery's job polling with backoff), and always fetch results after the job reports DONE.

data agent timed out waiting for bigquery job: polling pattern

Use this when

• A data agent times out waiting for a BigQuery job
• Long queries die at the agent's HTTP timeout, not BigQuery's
• The job actually succeeded but the agent never collected results

Not for this skill when

• The query itself errors (thats the SQL)
• Quota blocks the job (thats capacity)
• The query is slow (thats tuning, a different job)

Steps

1. Submit without blocking, then poll the job state:

job = client.query("SELECT ...")  # returns immediately
print(job.job_id, job.state)

Expected output: the job id and state (RUNNING). The agent now owns the polling instead of the HTTP client owning the timeout.

2. Wait with a timeout that matches the workload, and handle it:

try:
    rows = job.result(timeout=600)
except TimeoutError:
    print(f"job {job.job_id} still running; will re-check")

Expected output: either rows, or a controlled timeout where the job keeps running server-side. The job is not lost on timeout; only the wait gave up.

3. On timeout, re-attach to the same job instead of resubmitting:

job = client.get_job(job.job_id)
rows = job.result(timeout=600)

Expected output: results from the original job. Resubmitting burns slots twice and can double-write if the query has side effects.

4. For fire-and-forget pipelines, poll with backoff in the orchestrator:

import time
while job.state != "DONE":
    time.sleep(10)
    job.reload()

Expected output: the loop exits when the job finishes. Cap the loop with a max wait and alert rather than looping forever.

Variant phrasings

agent reports the query failed but BigQuery shows success

The wait timed out, not the query. The results are sitting in the job; re-attach (step 3).

timeouts only on the first run of the day

Cold slots and cold caches make the first query slow. The polling pattern absorbs this; a fixed short timeout doesnt.

Why it happens

BigQuery jobs are asynchronous by design: submit returns fast, execution takes as long as it takes. Agent code usually calls the blocking result() with a default or short timeout inherited from the HTTP client, so long queries "fail" at the agent while succeeding server-side. The polling pattern respects the async model instead of fighting it.

Edge cases

• job.result() with no timeout blocks forever; always pass one in agent code.
• Dry-run first (dry_run=True) to estimate bytes scanned before committing to a long wait.
• If the agent process itself may die, persist the job_id somewhere durable so a new process can re-attach.

Provenance

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

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

Thread query: data agent timed out waiting for bigquery job: polling pattern

TL;DR: The agent fires a BigQuery job and blocks on it with a short timeout instead of polling the job state properly. Fix it by submitting the job, then polling job.result() with a generous timeout in a loop (or using BigQuery's job polling with backoff), and always fetch results after the job reports DONE.