execDbtCompile / execDbtCompileInline mask real dbt errors with generic wrapper message #943

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

• altimate-dbt execute masks real dbt show error with generic "Could not parse" message #932 / fix: bubble real dbt show error instead of generic "Could not parse" #933 — the same fix was applied to execDbtShow. Adjacent code path, distinct review surface, hence a separate issue.