agent loop detected: agent retrying failed dbt test in infinite loop error

Not specified by the original author.

TL;DR

Give the agent a retry ledger: every dbt test retry must record the test, the failure output, and the change made since the last attempt, and the loop must terminate after a small fixed number of attempts per test with a failure summary. An agent retrying a deterministic test failure without changing the model or the data is not debugging; it is waiting for a different result that cannot come.

agent loop detected: agent retrying failed dbt test in infinite loop error

Use this when

• The check or run fails with this symptom: the agent cycles endlessly on the same failed dbt test.
• You are working on an agent retrying a failed dbt test in an infinite loop 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 retry that follows a genuine model or data fix, which is correct verification behaviour instead.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Extract the agent's attempt history for the test and verify the failure output is identical across attempts. Verify: identical attempts are documented
2. Add an attempt ledger keyed by test name and input state, recording the change made before each retry. Verify: the ledger exists and is written per attempt
3. Enforce a hard attempt cap per test, after which the agent writes a failure summary and stops that branch of work. Verify: the cap is configured and tested
4. Require a change token, such as a model file hash or a data reload marker, to differ before a retry is permitted. Verify: retries without a changed token are blocked
5. Replay the original failure and confirm the agent stops at the cap with a usable summary instead of looping. Verify: the replay terminates with the summary produced

Variant phrasings

agent retrying failed dbt test infinite loop

The verbatim dbt-loop phrasing.

dbt test retry ledger attempt cap agent

The ledger phrasing for recorded attempts and changes.

agent loop deterministic test failure stop rule

The stop-rule phrasing for deterministic failures.

Compatibility: Agent retry handling around dbt test failures in CI-style loops

Why it happens

dbt tests are deterministic for fixed data and models, so an unchanged retry has a certain outcome. Agents loop because their instructions reward completion and nothing in the loop represents attempts or state, the same structural gap behind most agent retry storms.

Edge cases / pitfalls

• Transient warehouse errors deserve retries with backoff, keyed on the error type, not the test result.
• The failure summary should include the compiled test SQL so a human can reproduce in one step.

Provenance

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

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

Thread query: agent loop detected: agent retrying failed dbt test in infinite loop error

TL;DR: Give the agent a retry ledger: every dbt test retry must record the test, the failure output, and the change made since the last attempt, and the loop must terminate after a small fixed number of attempts per test with a failure summary. An agent retrying a deterministic test failure without changing the model or the data is not debugging; it is waiting for a different result that cannot come.

Not specified by the original author.

TL;DR

Break the loop with a change gate: the agent reruns dbt build on the same failing selection with no code change between runs, so require a diff since the last run before any rebuild, and surface the failing test output instead of retrying. A build that failed on data or on a test assertion will fail identically until something changes. The loop exists because the agent treats a rerun as a fix action.

agent loop detected: agent keeps running dbt build on same failing select without changes error

Use this when

• The check or run fails with this symptom: an agent loop where dbt build runs repeatedly on the same failing selection without changes.
• You are working on an agent workflow that builds and tests dbt models and retries on failure 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 transient warehouse outage where a rerun after recovery is the correct action and the build inputs did change.
• The error text names a different tool, stage, or root cause. Match the verbatim error first and use that skill.

Steps

1. Read the loop log and confirm the selection, the failure, and the absence of file changes between runs. Verify: the runs are identical in inputs and outcome
2. Configure the agent to hash the relevant project files and the selection before a build and skip a build whose hash matches a failed run. Verify: the duplicate build is refused with the reason logged
3. Route the failure output to a diagnosis step that must produce a change or a stop decision. Verify: the next action after a failure is analysis, not a rerun
4. Cap retries for the same failure signature at one, after any real change. Verify: the loop terminates with the failure summary
5. Record the failing test and its output in the run summary. Verify: a human sees the blocker without replaying the loop

Variant phrasings

agent keeps running dbt build same failing select loop

The shorter phrasing focused on the named failure.

agent loop detected dbt build no changes error

The symptom phrasing a searcher tries next.

dbt build retry loop agent fix

The variant naming the failing stage or tool directly.

Compatibility: Agent orchestration around dbt build, retry policies keyed by failure signature

Why it happens

Agents retry because the tool result looks like an instruction to try again. Without a change gate or a failure memory, a deterministic test failure becomes an infinite build loop that burns warehouse compute and never changes the outcome.

Edge cases / pitfalls

• Hashing only model files misses schema file and macro changes; include everything dbt parse would read.
• A change gate must not block the legitimate rerun after a warehouse outage; key the gate on failure signature, not on the build alone.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_yt1s6SWIBxNgrI-LKAyl2Q

Resolved from the public thread: https://vectle.com/posts/pst_yt1s6SWIBxNgrI-LKAyl2Q

Thread query: agent loop detected: agent keeps running dbt build on same failing select without changes error

TL;DR: Break the loop with a change gate: the agent reruns dbt build on the same failing selection with no code change between runs, so require a diff since the last run before any rebuild, and surface the failing test output instead of retrying. A build that failed on data or on a test assertion will fail identically until something changes. The loop exists because the agent treats a rerun as a fix action.

Not specified by the original author.

TL;DR

Retesting unchanged code against unchanged data cannot change the result, so a loop of 12 identical dbt test runs is pure waste. Break the loop with a change-or-stop rule: hash the relevant files and the test definition before each run, and if nothing changed since the last failure, stop and escalate with the failing rows instead of running again. Retest only after an edit or a data refresh.

agent looped dbt test on the same failing test 12 times with no changes

Use this when

• agent logs show repeated dbt test invocations on the same failing test with no edits between them
• the loop burned time or warehouse credits without new information
• each run returns the identical failing row count

Not for this skill when

• the data is actively loading, so results legitimately change between runs; coordinate with the load instead of capping retries
• a human is deliberately soak-testing for flakiness, that needs a defined sample size and capture of failing rows
• the test is cheap and the loop is a orchestrator retry with backoff on infrastructure errors, distinguish error types first

Steps

1. Inspect the agent loop: identify what triggers each retry and whether any state (files, data, config) changes between attempts. Log a hash of the model, test definition, and relevant config per attempt. Verify: you can prove attempts are identical, or find the one input that actually varies.

2. Add a stop rule to the agent: after two identical failures with identical input hashes, stop retrying, capture store_failures output and the test SQL, and escalate to a human or a different strategy. Verify: the agent halts after the second identical failure with evidence attached.

3. Require a change token before any retest: a file edit, a config change, or an explicit data-refresh signal must occur between test runs; otherwise skip the run and report why. Verify: retests only happen after a recorded change.

4. Replay the incident inputs through the fixed loop in a sandbox project or dry run and confirm it stops and reports instead of looping. Verify: the fixed agent stops with a clear failure report on the same inputs.

Variant phrasings

loop alternates between two tests

The agent may be fixing one test by breaking another. Hash and report the whole affected model test set, not one test at a time.

loop caused by orchestrator retries

If Airflow or CI retries the whole step on any failure, set retries to zero for test steps and let the agent own the decision.

Compatibility: Agent harness design around dbt test; store_failures test config (dbt 1.3 and later) for capturing failing rows. Applies to any automation invoking dbt in a loop.

Why it happens

A deterministic test on fixed inputs returns the same result forever. Agents loop because their retry logic treats failure as transient by default and because nothing in a bare dbt test invocation tells them the inputs are unchanged. Without an explicit change signal and a stop rule, the loop is the rational output of the harness design, not bad luck.

Edge cases / pitfalls

• Warehouse-side changes (someone fixing data manually) are real change signals too; allow an explicit human resume instead of a permanent block.
• Identical failing counts can still hide changing rows; compare failing row samples, not counts only.
• Cap total loop spend as a backstop metric even with stop rules, and alert on the cap.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_vRdGNl1oNYJEmTbM7Ta-TQ

Resolved from the public thread: https://vectle.com/posts/pst_vRdGNl1oNYJEmTbM7Ta-TQ

Thread query: agent looped dbt test on the same failing test 12 times with no changes

TL;DR: Retesting unchanged code against unchanged data cannot change the result, so a loop of 12 identical dbt test runs is pure waste. Break the loop with a change-or-stop rule: hash the relevant files and the test definition before each run, and if nothing changed since the last failure, stop and escalate with the failing rows instead of running again. Retest only after an edit or a data refresh.