Mish Ushakov
5de9bc2354
## Summary
The flaky test `test_run_with_too_short_timeout_iterating` failed
intermittently because, when iterating a background command's output,
the Python SDK sets the HTTP stream `read` timeout to the command
`timeout` — so it races the server's own `deadline_exceeded` response.
When the client read timeout won, a raw `httpcore.ReadTimeout` leaked
out instead of a `TimeoutException`. This PR maps
`httpcore.TimeoutException` to `TimeoutException` in
`handle_rpc_exception`, so callers get a consistent timeout error
regardless of which side fires first, plus unit tests for the mapping.
It also adds a JS parity test (JS was never affected — connect-es always
normalizes timeouts into an already-mapped `ConnectError`).
## Usage
```python
cmd = sandbox.commands.run("sleep 10", timeout=2, background=True)
try:
for _ in cmd:
pass
except TimeoutException:
print("command timed out") # now raised reliably, no raw httpcore.ReadTimeout
```
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
488 B
488 B
@e2b/python-sdk
| @e2b/python-sdk |
|---|
| patch |
Map transport-level timeouts from httpcore (e.g. a stream read timeout) to TimeoutException. When iterating over a long-running command's output, the underlying HTTP read timeout (set to the command timeout) races with the server's own deadline_exceeded response; whichever fires first won, so the client could leak a raw httpcore.ReadTimeout instead of a TimeoutException. Both cases now surface a consistent, actionable TimeoutException.