chore: bump e2b to 2.39.0 (JS) and 2.39.1 (Python)

[mishushakov]

Bumps e2b in both packages — JS ^2.28.0 → ^2.39.0 and Python ^2.26.0 → ^2.39.1 — with both lockfiles regenerated and a patch changeset. The Python side needed two fixes, both fallout from the SDK's pyqwest migration in 2.38.0.

1. The http2 parameter (fixed upstream). Jupyter requests pin HTTP/1.1 via get_transport(config, http2=False), and 2.38.0 dropped that parameter, so every _client access raised TypeError. It was an intentional SDK capability — the transport cache key was literally (http2, proxy) in 2.32.0 — and the migration removed it without a release note, since the helper is internal. @e2b/python-sdk@2.39.1 restores it on both get_transport and get_envd_transport, so no code change is needed here; the floor is ^2.39.1 because anything in >=2.38.0, <2.39.1 breaks every execution. Pinning HTTP/1.1 matters because HTTP/2 multiplexing means a cancelled request resets only the stream, so the server never receives the http.disconnect that template/server/messaging.py relies on to interrupt the kernel.

2. run_code's timeout was inert (fixed here). The new transport does not implement httpx's per-phase timeouts — it derives one whole-request deadline and takes the longest non-connect phase. Passing timeout as the read timeout alongside request_timeout on write and pool made the effective deadline max(timeout, request_timeout), silently discarding any timeout below 60s. That is what failed CI: run_code(timeout=3) ran ~57s, outliving the fixture's 60s sandbox, and the next call returned a 502 "The sandbox was not found" surfaced as a sandbox TimeoutException. timeout now bounds the request on its own, and timeout=0 disables the deadline rather than inheriting the connect timeout.

Note that timeout is consequently a hard deadline on the request rather than an idle read bound, so an execution streaming output continuously for longer than timeout is now cut off. That matches the documented meaning and the JS SDK's body-abort timer (js/src/sandbox.ts:256), and the bumped SDK already bounded such executions by request_timeout regardless of timeout; a true per-request idle bound isn't expressible on this stack, since pyqwest only offers one per transport.

New python/tests/test_execute_timeout.py covers the regression offline (8 cases) and fails on a bare tuple or a request_timeout left on the write or pool phase. Full CI is green, including both interrupt tests — which now complete in ~6-8s instead of timing out — plus tsc --noEmit on the JS package, which reaches Jupyter through global fetch and needed no change.

🤖 Generated with Claude Code

[cursor]

PR Summary

Medium Risk
Dependency upgrades plus a change to how code-execution deadlines are enforced on the Jupyter stream; behavior is corrected but affects every Python run_code call.

Overview
Bumps the e2b dependency to 2.39.0 in the JS package and ^2.39.1 in Python, with lockfile updates and a patch changeset. Python 2.39.1 is the minimum because 2.38.x breaks Jupyter calls that pass http2=False to pin HTTP/1.1.

In sync and async run_code, the streaming /execute request now passes httpx.Timeout so timeout sets read/write/pool and request_timeout only connect, instead of a per-phase tuple where the pyqwest stack used max(timeout, request_timeout) and ignored short execution timeouts. timeout=0 uses httpx.Timeout(None) so no execution deadline is applied.

Adds test_execute_timeout.py to assert those timeout values reach the HTTP client for sync and async run_code.

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

[claude]

This is a version-bump PR, but it breaks the Python SDK: e2b 2.38.0 changed get_transport() to no longer accept the http2 kwarg, and both code_interpreter_sync.py and code_interpreter_async.py still pass http2=False. That will raise a TypeError on first use of _client in every sync/async sandbox call, so this needs a fix before merging (see inline comment).

Extended reasoning...

Verified directly against the actual e2b 2.38.0 wheel: both e2b/api/client_sync/__init__.py and e2b/api/client_async/__init__.py define get_transport(config) with a single positional parameter and no **kwargs. This repo's code_interpreter_sync.py:84 and code_interpreter_async.py:89 call get_transport(self.connection_config, http2=False), which will raise TypeError: get_transport() got an unexpected keyword argument 'http2' the first time _client is accessed — i.e., on essentially every run_code/context call in both sandbox flavors. This is a real, high-severity regression introduced by the dependency bump (the PR itself only touches lockfiles/manifests, but the new pinned version is incompatible with existing call sites), not a false positive from the finder agents. Deferring rather than approving.