agent's dbt debug passed but dbt run failed: profile target mismatch

TL;DR

dbt debug checks the target it resolves, which may not be the target the run used (different --target flag, environment variable, or working directory). Print the resolved target for both invocations exactly as the agent runs them, align flags and DBT_* environment, and rerun. Debug only proves the target it actually tested.

agent's dbt debug passed but dbt run failed: profile target mismatch

Use this when

• dbt debug reports all checks ok but dbt run fails on connection, schema, or permissions
• the agent runs debug and run from different directories, shells, or CI steps
• multiple targets exist (dev, ci, prod) with different schemas or credentials

Not for this skill when

• debug and run provably use the same target and run fails on SQL, debug never promised SQL correctness; debug the SQL
• debug itself fails, follow the debug failure directly
• the difference is the warehouse being down between the two calls, check timing before redesigning flags

Steps

1. Capture resolution for both commands: run dbt debug and note the profile, target name, schema, and host it prints; then run the failing command with the same verbosity and record the target it reports in its logs or in run_results invocation details. Verify: you have the resolved target details for both invocations side by side.

2. Diff the invocation context: compare --target and --profiles-dir flags, DBTTARGET and related environment variables, and the working directory (which changes which dbtproject.yml and profiles get found). Verify: the exact differing flag, variable, or directory is identified.

3. Align them: make the agent pass identical target and profiles arguments to debug and run, from the same working directory, and log the resolved target at the start of every automated run. Verify: both commands resolve the same target in a test execution.

4. Rerun debug then run back to back on the aligned setup: debug ok should now be followed by a run that at least connects and fails only on genuine model issues, if any. Verify: run behavior matches the debug prediction for connection and permissions.

Variant phrasings

works interactively, fails in the agent shell

Interactive shells load profile scripts that set environment variables the agent shell lacks. Export the needed DBT variables in the agent environment definition, not in shell rc files.

dbt Cloud debug equivalent

Cloud connection tests test the environment connection, while a job may override target settings. Compare job target overrides against the environment connection test.

Compatibility: dbt-core profile and target resolution (flags override env vars override profile defaults). dbt debug validates connection and basic config for the resolved target only.

Why it happens

Target resolution is contextual: flags, environment, directory, and profile defaults combine per invocation. Two commands that look the same can resolve different targets when any context differs, and dbt debug honestly validates the one it resolved. The paradox dissolves once resolution is printed and compared, because the run was never testing the debug target.

Edge cases / pitfalls

• Schemas that embed the target name (generateschemaname using target.name) make a target mismatch look like missing tables; the giveaway is a wrong schema prefix.
• Pin the target explicitly in automation; defaults are for humans at terminals.
• A profiles.yml edited between debug and run (agent fixing credentials mid-flight) creates the same paradox; sequence edits before both commands.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_1DSZZFF-7CVjMODs7RZSlw