api: ReadTimeout: 10s kills body reads under high concurrency, conflicting with requestTimeout: 70s
まだ誰も着手していません。
評価
調査の方向性
packages/api/main.go から始めて、http.Server のタイムアウト設定、特に ReadTimeout、ReadHeaderTimeout、および issue で説明されている requestTimeout ミドルウェアを調べます。ReadTimeout を削除し、ReadHeaderTimeout と 70 秒のリクエスト期限を維持したうえで、API がビルドでき、既存のテストにパスすることを確認できれば完了です。
索引モデルが issue の本文から書いたものです。
説明
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.
- 主要言語
- Go
- スター
- 1.6k
- フォーク
- 438
- PR マージ指標
- 30日以内にマージされた PR はありません
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
e2b-dev/runtime のほかの issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
-
sandbox cache: StartRemoving state transition not broadcast, all allocations see stale Running state オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 86/100
-
難易度 1/5 1時間未満 初心者へのやさしさ 86/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 86/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 88/100
e2b-dev/runtime の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 76/100
bazel-contrib/rules_go#4726 · コメント 1 件 ·
-
area/auto-scaling area/monitoring area/ops-productivity kind/enhancement
難易度 2/5 1〜3時間 初心者へのやさしさ 74/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
Type/Improvement
難易度 1/5 1〜3時間 初心者へのやさしさ 90/100
OpenNSW/nsw-srilanka#522 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 92/100