fix(sdk): select stack-trace frames by SDK boundary instead of fixed depth

[mishushakov]

Description

Template build stack traces were captured by walking a fixed number of frames (STACK_TRACE_DEPTH plus ±1 arithmetic at ~15 call sites), which broke whenever the frame count between new Error() and user code shifted — TS class-field initializer frames (#1539) and Bun's tail-call frame elision were both this bug. This PR makes two related changes:

1. Boundary-based frame selection. The caller's frame is now the first one whose file lies outside the SDK package, making extra transpiler frames and elided delegating frames irrelevant. In the JS SDK, frame parsing is delegated to error-stack-parser-es (ESM-only, so it's a devDependency inlined into both dist formats via tsdown noExternal — the engines range includes Node versions without require(esm)); the Python SDK equivalently walks f_back until co_filename leaves the e2b package root, in the shared builder used by both sync and async. If no user frame is identifiable (e.g. the SDK is bundled into the caller's own file), capture degrades to no trace rather than a wrong frame.
2. Dead machinery removed. Because boundary capture resolves through SDK-internal delegation (remove() → runCmd(), fromDockerfile() → parser) to the user's call site on its own, the suppress/override collection machinery (runInNewStackTraceContext, runInStackTraceOverrideContext, the enabled/override flags, and their Python equivalents) became redundant and is removed — superseding the approach in feat(js-sdk): run the template test suite on Bun #1596.

Error .stack synthesis (keeping the Name: message header and the throw site on cause) was prototyped here and backed out — it will come as a follow-up PR.

Usage

No API changes — build errors now point at the user's call site regardless of runtime or transpiler:

const template = Template()
  .fromBaseImage()
  .runCmd('./does-not-exist') // ← build failures point exactly here

await Template.build(template, 'my-template')

Testing

• JS: unit + template vitest projects green against the real API (incl. 27 per-method stacktrace tests pinning exact call-site line/columns, bunInstall now covered); edge-compat bundle test and CLI build verified; built CJS/ESM dists smoke-tested with require()/import().
• Python: all 184 template tests green (shared + sync + async, incl. both test_stacktrace.py suites, bun_install now covered); ruff and ty clean.

🤖 Generated with Claude Code

[changeset-bot]

🦋 Changeset detected

Latest commit: 4e3aa98

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 2 packages

Name	Type
e2b	Patch
@e2b/python-sdk	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[cursor]

PR Summary

Medium Risk
Touches error attribution across both SDKs' template builders with no public API change; wrong boundary logic would mis-point build failures, but behavior is heavily covered by stacktrace tests.

Overview
Template build errors now attribute steps to the user's call site by picking the first stack frame outside the SDK package, instead of a fixed STACK_TRACE_DEPTH. That stays correct when transpilers add frames (e.g. TS class fields) or runtimes skip delegating frames (e.g. Bun).

JS: getCallerFrame / getCallerDirectory use error-stack-parser-es and SDK-directory boundary detection; STACK_TRACE_DEPTH and stack-trace override helpers (runInNewStackTraceContext, runInStackTraceOverrideContext, enable/disable flags) are removed so delegating methods like remove() → runCmd() still record the right site.

Python: Same boundary walk via inspect and the e2b package root; equivalent override machinery is removed.

Tests add bunInstall stacktrace coverage and assert caller resolution from outside the SDK; JS bundles the parser via tsdown noExternal.

^{Reviewed by Cursor Bugbot for commit 4e3aa98. Bugbot is set up for automated code reviews on this repo. Configure here.}

[github-actions]

Package Artifacts

Built from d823efc. Download artifacts from this workflow run.

JS SDK (e2b@2.35.4-boundary-based-stack-frames.0):

npm install ./e2b-2.35.4-boundary-based-stack-frames.0.tgz

CLI (@e2b/cli@2.15.1-boundary-based-stack-frames.0):

npm install ./e2b-cli-2.15.1-boundary-based-stack-frames.0.tgz

Python SDK (e2b==2.34.0+boundary.based.stack.frames):

pip install ./e2b-2.34.0+boundary.based.stack.frames-py3-none-any.whl

[linear-code]

SDK-263