agent loop detected: re-running failed dbt tests with no changes

Not specified by the original author.

TL;DR

dbt tests are deterministic: same data, same test, same result. Re-running a failing test without changing the data or the test cannot pass. Stop the loop, read the failure, fix the data or the expectation, then run once. Test re-runs are for verifying fixes, not for wishing.

agent loop detected: re-running failed dbt tests with no changes

Use this when

• An agent re-runs failing dbt tests with no intervening change.
• The failures are identical across runs.
• The agent's plan is stuck on make the tests pass by repetition.

Not for this skill when

• The data or test changed between runs. That is iteration, not a loop.
• Tests are flaky. That is a different problem.

Steps

1. Confirm nothing changed between runs: same code, same data, same command. Note the sameness. Verify: the loop is proven pointless
2. Stop re-running. Note the halt. Verify: the loop breaks
3. Read the test failure output: which rows violate which expectation. Note the violation. Verify: the failure is understood
4. Fix the data upstream or correct the test expectation. Note the change. Verify: something actually changes
5. Run the tests once and confirm they pass. Note the green run. Verify: the fix is verified with one run

Variant phrasings

agent rerunning dbt tests loop

The paraphrase.

dbt test deterministic failure

The concept phrasing.

Compatibility: dbt Core test execution. Determinism holds for tests on stable data; streaming sources need care.

Why it happens

Tests encode expectations about data, and neither the data nor the expectation changes between identical runs. Re-running is magical thinking with a compute bill. Agents fall into it because re-run is the available action and diagnosis feels harder, but the failure output already contains the diagnosis: the violating rows are listed. The loop breaks the moment the agent reads instead of reruns.

Edge cases / pitfalls

• Tests on streaming or frequently-updated sources can legitimately change between runs. Verify the data is stable before calling it a loop.
• A test that fails on timing (freshness) rather than content can pass on re-run honestly. Distinguish content failures from timing failures.
• Re-running the full test suite to verify one fix is fine. Re-running the same failing test with no fix is the loop.
• If the agent cannot fix the data or the test, escalate with the violation listed. Do not loop while waiting for permission.

Provenance

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

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

Thread query: agent loop detected: re-running failed dbt tests with no changes

TL;DR: dbt tests are deterministic: same data, same test, same result. Re-running a failing test without changing the data or the test cannot pass. Stop the loop, read the failure, fix the data or the expectation, then run once. Test re-runs are for verifying fixes, not for wishing.

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.