api: ReadTimeout: 10s kills body reads under high concurrency, conflicting with requestTimeout: 70s
Chưa có ai nhận issue này.
Đánh giá
- Độ khó
- 1/5
- Thời gian dự kiến
- Dưới một giờ
- Mức phù hợp với người mới
- 85/100
Hướng nghiên cứu
Bắt đầu trong packages/api/main.go và kiểm tra cấu hình timeout của http.Server, đặc biệt là ReadTimeout, ReadHeaderTimeout và middleware requestTimeout được mô tả trong issue. Hoàn tất có nghĩa là xóa ReadTimeout, giữ lại ReadHeaderTimeout và thời hạn 70 giây cho request, sau đó xác minh rằng API build thành công và các bài kiểm thử hiện có đều pass.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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.
- Ngôn ngữ chính
- Go
- Star
- 1.6k
- Fork
- 438
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của e2b-dev/runtime
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
-
sandbox cache: StartRemoving state transition not broadcast, all allocations see stale Running state Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 86/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 86/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
Tất cả issue của e2b-dev/runtime
Issue tương tự
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
prometheus/procfs#872 ·
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 76/100
bazel-contrib/rules_go#4726 · 1 bình luận ·
-
area/auto-scaling area/monitoring area/ops-productivity kind/enhancement
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 74/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 75/100