Symptom
When dbt compile or dbt compile --inline fails with a real dbt error (e.g. Compilation Error: Model 'foo' depends on a node named 'bar' which was not found), execDbtCompile and execDbtCompileInline in packages/dbt-tools/src/dbt-cli.ts surface a generic wrapper message that masks the actual cause. Users see "Could not compile … Last error: Command failed: …" instead of the structured dbt error they need to fix the problem.
Root cause
Both functions wrap run() in a try { … } catch { lines = [] } that swallows the run-time error entirely:
// execDbtCompile
try {
const { stdout } = await run(args)
lines = parseJsonLines(stdout)
} catch {
lines = []
}// execDbtCompileInline — same pattern
The structured level: "error" event present in dbt's JSON log on a crashed run is never inspected, and the final throw embeds Node's generic Command failed: … message rather than dbt's category-prefixed error (Compilation Error: …, Database Error: …, etc.).
Expected
Both functions should mirror the pattern already in place for execDbtShow: capture the run error, parse level: "error" events from any partial stdout, and surface the real dbt error via the existing extractDbtError helper (with the same SQL-redaction guarantees provided by fallbackExitMessage).
Suggested fix
Extract a shared runWithErrorBubbling(args, label) helper from the execDbtShow pattern and apply to all three execDbt* functions, so error UX is consistent across the surface.
Related
Symptom
When
dbt compileordbt compile --inlinefails with a real dbt error (e.g.Compilation Error: Model 'foo' depends on a node named 'bar' which was not found),execDbtCompileandexecDbtCompileInlineinpackages/dbt-tools/src/dbt-cli.tssurface a generic wrapper message that masks the actual cause. Users see"Could not compile … Last error: Command failed: …"instead of the structured dbt error they need to fix the problem.Root cause
Both functions wrap
run()in atry { … } catch { lines = [] }that swallows the run-time error entirely:// execDbtCompileInline — same patternThe structured
level: "error"event present in dbt's JSON log on a crashed run is never inspected, and the final throw embeds Node's genericCommand failed: …message rather than dbt's category-prefixed error (Compilation Error: …,Database Error: …, etc.).Expected
Both functions should mirror the pattern already in place for
execDbtShow: capture the run error, parselevel: "error"events from any partial stdout, and surface the real dbt error via the existingextractDbtErrorhelper (with the same SQL-redaction guarantees provided byfallbackExitMessage).Suggested fix
Extract a shared
runWithErrorBubbling(args, label)helper from theexecDbtShowpattern and apply to all threeexecDbt*functions, so error UX is consistent across the surface.Related
execDbtShow. Adjacent code path, distinct review surface, hence a separate issue.