fix(dbt-tools): move to dbt-integration 0.3.13 so the dbt adapter starts under Bun

[ralphstodomingo]

Issue for this PR

Closes #1367

Type of change

• Bug fix

What does this PR do?

Moves packages/dbt-tools from @altimateai/dbt-integration 0.2.14 to ^0.3.13. 0.2.x started its Python child through python-bridge, which fails to load under Bun (bluebird.promisifyAll on child_process throws Cannot access invalid private field (evaluating 'this.#stdin')), so the dbt-first path of sql_execute never ran. 0.3.x vendors the bridge and uses a plain fd-3 pipe; python-bridge and bluebird leave the lockfile.

• adapter.ts: 0.3.x's DBTProjectIntegrationAdapter takes a UnitTestParser and a SemanticModelParser; the Fusion integration no longer takes the cloud-variant detector (the Cloud integration still does).
• copy-python.ts: the vendored bridge finds node_python_bridge.py from the bundle's own location at runtime (fileURLToPath(import.meta.url) → dist/), so the python-bridge __dirname patch is removed. The build now fails if a build-time path is ever baked in. build-adversarial.test.ts only tested that removed patch, so it goes; build-integrity.test.ts and the release smoke check assert the new invariant.

Not fixed here — the compiled binary. altimate bundles the library into the binary, where the bridge looks for its script at /$bunfs/root/node_python_bridge.py, which the Python child can't open. From source and from the npm altimate-dbt (Node) the adapter works; in the binary the failure changes from the #stdin TypeError to "can't open file" (still caught by ensureDbtAdapter, so no behaviour change for users there). That needs a change in @altimateai/dbt-integration, tracked on the issue.

How did you verify your code works?

• packages/dbt-tools: bun run typecheck clean, bun run build passes the new guard, bun run test 83 pass.
• Against a dbt 1.11.7 / DuckDB project with its own venv, building the adapter through dbt-tools under Bun 1.3.14:
  • main (0.2.14): create fails with TypeError: Cannot access invalid private field (evaluating 'this.#stdin').
  • this branch (0.3.13): create succeeds in ~5 s, getDBTVersion() returns [1, 11, 7] through the Python child, and immediatelyExecuteSQL("select 1 …") returns the row.
• The built dist/index.js under Node (altimate-dbt info / execute --query "select 1 as one") returns the project and [{"one": 1}].
• The same probe compiled with bun build --compile fails with can't open file '/$bunfs/root/node_python_bridge.py' — the open item above.

Checklist

• I have tested my changes locally
• I have not included unrelated changes in this PR

Appendix — complexity delta (dbt-tools on dbt-integration 0.3.13)

282e784055 → 3ef53864ba · only functions this diff touches · advisory, not a gate.

✅ No touched function changed in complexity (2 touched, 0 new, all under 10).

ℹ️ How to read these numbers

Cognitive (Sonar spec) counts breaks in linear reading flow — each if/loop/catch/ternary/boolean-operator switch adds 1, and nesting makes every further break cost more. It approximates how much you must hold in your head to follow the function: 0–5 trivial · 6–10 easy · 11–15 moderate (15 = Sonar's recommended per-function cap) · 16–25 hard to follow · >25 needs decomposition.

CCN (cyclomatic) counts independent paths — also the minimum number of test cases for full branch coverage of the function.

Only functions this diff touches are measured, as deltas — pre-existing complexity is not counted against this change. Rising numbers aren't automatically wrong; they're where review attention should go. Test files excluded.

🤖 Generated with Claude Code

https://claude.ai/code/session_0172qrhMa5TQgETASi5hxMqD

---

Summary by cubic

Fixes #1367 by upgrading packages/dbt-tools to @altimateai/dbt-integration 0.3.13 so the dbt adapter's Python child starts under Bun. The previous 0.2.x loaded Python through python-bridge, which crashes under Bun (bluebird.promisifyAll on child_process throws Cannot access invalid private field), so the dbt-first path of sql_execute never ran; 0.3.x vendors the bridge and talks over a plain fd-3 pipe.

• The Fusion integration now supplies UnitTestParser and SemanticModelParser to the 0.3.x adapter and no longer passes the cloud-variant detector (the Cloud integration still does).
• The vendored bridge resolves node_python_bridge.py at runtime from the bundle's own location, so the old __dirname patch is removed and the build fails if a build-time path is baked in. build-adversarial.test.ts, which only tested that patch, is gone; build-integrity.test.ts and the release smoke check assert the new invariant.
• The compiled altimate binary still fails: the bridge can't open /$bunfs/root/node_python_bridge.py. Source and npm altimate-dbt builds work; the binary failure is caught by ensureDbtAdapter, so there's no user-facing behavior change there. The fix is tracked upstream.

^{Written for commit 3ef5386. Summary will update on new commits.}

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}