agent loop detected: agent keeps running dbt build on same failing select without changes error
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. Use when an agent workflow that builds and tests dbt models and retries on failure. Not for a transient warehouse outage where a rerun after recovery is the correct action and
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 errorUse 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
- 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
- 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
- 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
- Cap retries for the same failure signature at one, after any real change. Verify: the loop terminates with the failure summary
- 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