What happened
The E2B compatibility surface documents streamed file reads and writes as having no artificial size cap, with the sandbox disk quota as the cap. The Docker executor nevertheless wraps both streaming directions in GNU timeout --signal=KILL 3600, imposing a fixed one-hour wall-clock deadline independent of file size or client throughput.
Reproduction:
- Run a Docker sandbox through the official E2B SDK.
- Upload or download a valid file at a rate that makes the transfer take longer than one hour (for example, a multi-GiB file over a throttled connection).
- Observe the transfer fail when the in-container
timeout reaches 3600 seconds, despite the file fitting within the sandbox quota.
A deterministic focused test can scale the deadline by placing a timeout wrapper in the test image that maps only the 3600 argument to one second, then stream for two seconds through the official SDK. Both upload and download are killed at the scaled deadline.
Expected: A valid streaming transfer within the sandbox's disk quota can finish at the client's pace, subject to an explicit caller/request cancellation rather than a hidden fixed deadline.
Actual: Both directions are killed after 3600 seconds. A slow download may already have sent headers and part of its body when it is terminated.
Impact: Valid large files fail over slow or throttled links, making the documented disk quota unreachable as the effective transfer cap. Interrupted uploads can also leave only the bytes written before the kill.
Relevant code and contract:
packages/server/src/executor/docker-scripts.ts:52-57 defines the fixed 3600-second streaming deadline.
packages/server/src/executor/docker.ts:905-944 applies it to downloads.
packages/server/src/executor/docker.ts:946-981 applies it to uploads.
website/content/docs/e2b-differences.mdx:23-29 documents streamed file I/O without an artificial size cap.
dor doctor output
Not applicable: this is a Docker executor transfer behavior, not a host-readiness failure.
Environment
- Dormice commit:
4417ae14938273f5d937c476cf7cdc57e22e53a5
- Executor: Docker + gVisor
- Client surface: official E2B SDK streaming file APIs
- Verification: source-path trace and scaled-deadline black-box reproduction design
What happened
The E2B compatibility surface documents streamed file reads and writes as having no artificial size cap, with the sandbox disk quota as the cap. The Docker executor nevertheless wraps both streaming directions in GNU
timeout --signal=KILL 3600, imposing a fixed one-hour wall-clock deadline independent of file size or client throughput.Reproduction:
timeoutreaches 3600 seconds, despite the file fitting within the sandbox quota.A deterministic focused test can scale the deadline by placing a
timeoutwrapper in the test image that maps only the3600argument to one second, then stream for two seconds through the official SDK. Both upload and download are killed at the scaled deadline.Expected: A valid streaming transfer within the sandbox's disk quota can finish at the client's pace, subject to an explicit caller/request cancellation rather than a hidden fixed deadline.
Actual: Both directions are killed after 3600 seconds. A slow download may already have sent headers and part of its body when it is terminated.
Impact: Valid large files fail over slow or throttled links, making the documented disk quota unreachable as the effective transfer cap. Interrupted uploads can also leave only the bytes written before the kill.
Relevant code and contract:
packages/server/src/executor/docker-scripts.ts:52-57defines the fixed 3600-second streaming deadline.packages/server/src/executor/docker.ts:905-944applies it to downloads.packages/server/src/executor/docker.ts:946-981applies it to uploads.website/content/docs/e2b-differences.mdx:23-29documents streamed file I/O without an artificial size cap.dor doctor output
Not applicable: this is a Docker executor transfer behavior, not a host-readiness failure.
Environment
4417ae14938273f5d937c476cf7cdc57e22e53a5