api: ReadTimeout: 10s kills body reads under high concurrency, conflicting with requestTimeout: 70s
Maintainers usually reply within 3 days
Nobody has claimed this yet.
Assessment
- Difficulty
- 1/5
- Estimated time
- Under an hour
- Newbie friendliness
- 85/100
Research direction
Start in packages/api/main.go and inspect the http.Server timeout configuration, especially ReadTimeout, ReadHeaderTimeout, and the requestTimeout middleware described in the issue. Done means removing ReadTimeout while retaining ReadHeaderTimeout and the 70-second request deadline, then verifying the API builds and its existing tests pass.
Written by the indexing model from the issue text.
Description
Problem
Under high concurrency (e.g. 1 000 simultaneous sandbox creates) the API returns a flood of errors with:
reading failed: read tcp 192.168.0.146:3000->...: i/o timeout
Root cause
packages/api/main.go configures two competing timeouts:
| Setting | Value | Scope |
|---|---|---|
ReadTimeout |
10 s | Starts at TCP accept; covers headers + body |
requestTimeout |
70 s | Context deadline applied by middleware |
Go's http.Server.ReadTimeout starts counting from the moment the TCP connection is accepted — including scheduler queue time. Under high concurrency, goroutines may wait >10 s in the scheduler before they ever execute and call io.ReadAll. By then the ReadTimeout has already fired and the connection is dead.
requestTimeout: 70 s is the intended per-request ceiling but is never reached in practice because ReadTimeout: 10s fires first.
Why ReadHeaderTimeout is sufficient
ReadHeaderTimeout: 5s already guards against slowloris (headers never arrive). Once headers are received and ServeHTTP starts, request bodies on this API are small JSON payloads (<1 KB) sent in a single TCP segment — there is no meaningful slow-body attack surface. The requestTimeout: 70s middleware context provides the actual per-request deadline for handler execution.
Fix
Remove ReadTimeout from the http.Server config. Keep ReadHeaderTimeout for slowloris protection.
- Dominant language
- Go
- Stars
- 1.6k
- Forks
- 448
- PR merge metrics
- No merged PRs in 30d
Getting set up
Starts the project's dev container in your browser, under your own GitHub account.
- No Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from e2b-dev/runtime
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 3 days
-
sandbox cache: StartRemoving state transition not broadcast, all allocations see stale Running stateOpen
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 3 days
-
Difficulty 1/5 Under an hour Newbie friendliness 86/100
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 86/100
Maintainers usually reply within 3 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
Maintainers usually reply within 3 days
Similar issues
-
flaky-test
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 85/100
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
SocialGouv/iterion#2108 ·
Maintainers usually reply within 1 day