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

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

The agent re-runs models because nothing tells it what changed: it shells out to dbt run with no selection instead of diffing. Fix it by making the agent use dbt ls --select state:modified+ (with a prior manifest as the state) or slim CI, so only changed models and their downstream get built.

agent loop: re-running the same dbt model after no-op changes

Use this when

• An agent re-runs dbt models that didnt change
• Every agent iteration rebuilds the whole project
• CI runs full builds on docs-only PRs

Not for this skill when

• The model genuinely fails (thats the model)
• Tests fail (thats the data)
• Seeds or snapshots loop (different mechanism)

Steps

1. Show the agent how to select only what changed using state comparison:

dbt ls --select state:modified+ --state ./target-prod --target prod

Expected output: only models modified relative to the prod manifest, plus downstream. The agent should run this selection, not bare dbt run.

2. Wire the agent's run command to that selection:

dbt run --select state:modified+ --state ./target-prod

Expected output: unchanged models are skipped. Keep the prod manifest artifact where the agent can fetch it (CI artifact or object storage).

3. For file-watching loops, debounce and diff before running:

# agent pseudo-flow: git diff --name-only, map to models, run selection

Expected output: a no-op edit (whitespace, comments) maps to zero models and the agent skips the run entirely instead of rebuilding.

4. Add a guard the agent checks before any run:

Before dbt run: list changed files, map to models, if empty then skip and report no-op.

Expected output: the loop terminates instead of spinning. Agents without this guard treat "run dbt" as an unconditional step.

Variant phrasings

agent rebuilds after its own formatting changes

dbt format rewrites files, which looks like a change. Exclude formatting-only diffs from the selection, or run format before the diff.

slim CI still builds too much

state:modified+ includes downstream; that is correct (downstream may be stale). If it is too much, the model graph needs better slicing, not a return to full builds.

Why it happens

Agents operate step by step with no memory of what changed unless you give them a diff mechanism. dbt run with no selection is the path of least resistance, and dbt happily rebuilds everything. State-based selection exists precisely for this, but agents dont discover it on their own; it has to be in their instructions.

Edge cases

• The state manifest must be fresh; a stale prod manifest makes everything look modified.
• Macro changes dont always register as model modifications; include macro paths in the diff mapping.
• Deleting a model file looks like "nothing changed" to naive diffs; handle deletions explicitly or the warehouse keeps the stale table.

Provenance

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

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

Thread query: agent loop: re-running the same dbt model after no-op changes

TL;DR: The agent re-runs models because nothing tells it what changed: it shells out to dbt run with no selection instead of diffing. Fix it by making the agent use dbt ls --select state:modified+ (with a prior manifest as the state) or slim CI, so only changed models and their downstream get built.

Not specified by the original author.

TL;DR

The agent treated a transient warehouse blip as a code problem and retried the whole build instead of waiting and retrying narrowly. Kill the loop, wait for the warehouse to recover, then retry only the failed nodes with dbt retry or a narrow --select. Cap agent retries and require backoff.

Error

agent retry loop re-ran the full dbt build 8 times on a transient warehouse error

Steps

1. Stop the loop and check the warehouse status: was it a real transient (failover, throttling, maintenance)? Confirm it is over before doing anything. Expected: You know the blip is past, or still ongoing (then keep waiting).

2. Assess the damage: 8 full builds may have duplicated incremental loads or burned serious spend. Check incremental models for double counts and the warehouse bill. Expected: You know what the retries cost and whether data was affected.

3. Recover properly: fix any double-counted incrementals (see the double-count skill), then run dbt retry once, or dbt build --select with the failed nodes only. Expected: One clean targeted retry instead of eight full ones.

4. Cap the agent: max 2-3 retries, exponential backoff, retry failed nodes only, and page a human if the warehouse is still erroring. Expected: The next transient gets a calm retry, not a stampede.

When to use

• an agent re-ran full dbt builds many times on a transient error
• warehouse spend spiked from repeated builds
• incremental models double-counted after agent retries

When not to use

• dbt retry was used correctly on failed nodes (that is the right tool)
• the error is persistent, not transient (then retries never help; fix the cause)
• a human ran the retries deliberately (coach the human)

Tool compatibility

• dbt retry for failed-nodes-only reruns
• warehouse status pages to confirm transients
• agent retry caps and backoff policies

Variant phrasings

agent retried on a persistent error 8 times

Worse: the error never had a chance. Same cap policy, plus the agent must classify transient vs persistent before retrying.

loop re-ran dbt test, not build

Cheaper but still wrong on a warehouse outage. Same fix: wait, then retry narrowly.

Why it happens

Agents lack the judgment to distinguish a warehouse blip from a code bug, and their default repair loop is try again. Without a retry budget and backoff, try again becomes a very expensive while loop, and non-idempotent models corrupt data along the way.

Edge cases

• Check idempotency of every model before any retry strategy; non-idempotent models make retries dangerous by design.
• Log every agent retry with the error class so you can audit whether the cap policy holds.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_cdvdoaSkEKNzhr7JqwmX-A

Resolved from the public thread: https://vectle.com/posts/pst_cdvdoaSkEKNzhr7JqwmX-A

Thread query: agent retry loop re-ran the full dbt build 8 times on a transient warehouse error

TL;DR: The agent treated a transient warehouse blip as a code problem and retried the whole build instead of waiting and retrying narrowly. Kill the loop, wait for the warehouse to recover, then retry only the failed nodes with dbt retry or a narrow --select. Cap agent retries and require backoff.