[PR #377] [MERGED] fix(proxy): allow slow guest HTTP response headers

## 📋 Pull Request Information **Original PR:** https://github.com/kvcache-ai/AgentENV/pull/377 **Author:** [@LSX-s-Software](https://github.com/LSX-s-Software) **Created:** 10/13/2026 **Status:** ✅ Merged **Merged:** 10/14/2026 **Merged by:** [@yingdi-shan](https://github.com/yingdi-shan) **Base:** `main` ← **Head:** `fix/proxy-timeout` --- ### 📝 Commits (1) - [`0166171`](https://github.com/kvcache-ai/AgentENV/commit/0166171512bab560a0c0ccbf102e4f311113eb98) fix(proxy): separate HTTP and WS response header timeouts ### 📊 Changes **3 files changed** (+21 additions, -8 deletions) <details> <summary>View changed files</summary> 📝 `services/README.md` (+1 -1) 📝 `services/gateway/internal/server.go` (+9 -1) 📝 `src/api/proxy.rs` (+11 -6) </details> ### 📄 Description ## What Allow guest HTTP services to take longer than 30 seconds before sending response headers, while keeping WebSocket handshake protection and gateway routing behavior bounded appropriately. ## Why The node proxy previously used the same 30-second timeout for HTTP response headers and WebSocket handshakes. A guest service that legitimately needed more than 30 seconds to produce its first response headers received `504 Gateway Timeout`. ## Related issue N/A. ## Scope and non-goals This change only adjusts proxy timeout semantics. It does not change request-body idle handling, sandbox lifecycle timeouts, or response-body streaming behavior. ## Design and behavior changes - HTTP response-header timeout is now 600 seconds. - WebSocket handshake timeout remains 30 seconds and uses a separate constant. - The gateway keeps its route-resolution deadline for scheduler/control-plane work, while routed sandbox data-plane requests reuse the client context after node selection. - Request-body idle timeout remains 30 seconds and is reset by upload progress. ## Compatibility and operations - Public API or generated protocol: N/A. - Configuration or defaults: No new configuration; the HTTP response-header timeout is a fixed 600-second runtime default. - Snapshot manifest, artifact layout, or storage format: N/A. - Upgrade and rollback: Rolling upgrade is safe; rollback restores the previous shorter timeout. - Host requirements, permissions, ports, or dependencies: N/A. ## Validation - [x] `cargo fmt --all -- --check` - [x] `cargo test -p agentenv --lib proxy` - [x] `make -C services test` (run as `go test ./...` in `services/`) - [ ] Relevant Rust integration tests - [ ] `make clippy` - [ ] `make test-unit` - [ ] Generated clients/server regenerated with the documented `make` target - [x] Documentation updated - [ ] Benchmarks or performance comparison completed Commands and results: ```text cargo fmt --all -- --check passed cargo test -p agentenv --lib proxy 65 passed, 0 failed go test ./... (services/) passed ``` Skipped checks and reasons: `make clippy`, `make test-unit`, and integration suites were not run because this focused proxy change was validated with the relevant Rust unit tests and complete services test suite. No schema or generated-code changes are involved. ## Risks and reviewer notes The longer HTTP response-header deadline permits a stuck guest service to retain a connection for up to 10 minutes before the proxy releases it. The request-body idle timeout and WebSocket handshake timeout remain bounded. Review the context split in `services/gateway/internal/server.go` together with the timeout constants in `src/api/proxy.rs`. ## Checklist - [x] The PR contains one coherent change and no unrelated formatting or refactoring. - [x] New behavior is covered by existing proxy tests, including slow-header timeout behavior. - [x] Logs and examples contain no credentials, tokens, or private registry information. - [x] I did not manually edit generated code without updating its source and regenerating it. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi commented

2026-10-29 14:22:54 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/kvcache-ai/AgentENV/pull/377
Author: @LSX-s-Software
Created: 10/13/2026
Status: ✅ Merged
Merged: 10/14/2026
Merged by: @yingdi-shan

Base: main ← Head: fix/proxy-timeout

📝 Commits (1)

0166171 fix(proxy): separate HTTP and WS response header timeouts

📊 Changes

3 files changed (+21 additions, -8 deletions)

View changed files

📝 services/README.md (+1 -1)
📝 services/gateway/internal/server.go (+9 -1)
📝 src/api/proxy.rs (+11 -6)

📄 Description

What

Allow guest HTTP services to take longer than 30 seconds before sending response headers, while keeping WebSocket handshake protection and gateway routing behavior bounded appropriately.

Why

The node proxy previously used the same 30-second timeout for HTTP response headers and WebSocket handshakes. A guest service that legitimately needed more than 30 seconds to produce its first response headers received 504 Gateway Timeout.

N/A.

Scope and non-goals

This change only adjusts proxy timeout semantics. It does not change request-body idle handling, sandbox lifecycle timeouts, or response-body streaming behavior.

Design and behavior changes

HTTP response-header timeout is now 600 seconds.
WebSocket handshake timeout remains 30 seconds and uses a separate constant.
The gateway keeps its route-resolution deadline for scheduler/control-plane work, while routed sandbox data-plane requests reuse the client context after node selection.
Request-body idle timeout remains 30 seconds and is reset by upload progress.

Compatibility and operations

Public API or generated protocol: N/A.
Configuration or defaults: No new configuration; the HTTP response-header timeout is a fixed 600-second runtime default.
Snapshot manifest, artifact layout, or storage format: N/A.
Upgrade and rollback: Rolling upgrade is safe; rollback restores the previous shorter timeout.
Host requirements, permissions, ports, or dependencies: N/A.

Validation

cargo fmt --all -- --check
cargo test -p agentenv --lib proxy
make -C services test (run as go test ./... in services/)
Relevant Rust integration tests
make clippy
make test-unit
Generated clients/server regenerated with the documented make target
Documentation updated
Benchmarks or performance comparison completed

Commands and results:

cargo fmt --all -- --check                         passed
cargo test -p agentenv --lib proxy                 65 passed, 0 failed
go test ./... (services/)                           passed

Skipped checks and reasons:

make clippy, make test-unit, and integration suites were not run because this focused proxy change was validated with the relevant Rust unit tests and complete services test suite. No schema or generated-code changes are involved.

Risks and reviewer notes

The longer HTTP response-header deadline permits a stuck guest service to retain a connection for up to 10 minutes before the proxy releases it. The request-body idle timeout and WebSocket handshake timeout remain bounded. Review the context split in services/gateway/internal/server.go together with the timeout constants in src/api/proxy.rs.

Checklist

The PR contains one coherent change and no unrelated formatting or refactoring.
New behavior is covered by existing proxy tests, including slow-header timeout behavior.
Logs and examples contain no credentials, tokens, or private registry information.
I did not manually edit generated code without updating its source and regenerating it.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

bsakaguchi