You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 29, 2026. It is now read-only.
Repository navigation
This repository was archived by the owner on Sep 29, 2026. It is now read-only.
Add configurable timeouts to HTTP client and streaming responses #33
The proxy has no timeouts configured anywhere. The OpenSecretClient uses reqwest::Client::new() with no timeout settings, meaning requests and streaming responses can hang indefinitely if the backend stops responding or a connection drops mid-stream.
This affects:
Regular chat completions: can hang forever waiting for a response
Streaming SSE responses: the stream has no read timeout and no heartbeat timeout, so a dropped connection mid-stream will block indefinitely rather than surfacing an error to the client
Impact
Users running agentic workloads (e.g. via API with tools like OpenClaw) may encounter silent hangs rather than fast failures when connectivity issues occur. This makes it harder to implement retry logic on the client side since the error is never returned.
Proposed Fix
Add a configurable timeout via environment variable (e.g. MAPLE_REQUEST_TIMEOUT_SECS, defaulting to something reasonable like 300s for streaming). Apply it when constructing the reqwest client:
For streaming specifically, a separate read/idle timeout may also be worth considering to handle cases where the server starts a response but stalls mid-stream.
Problem
The proxy has no timeouts configured anywhere. The
OpenSecretClientusesreqwest::Client::new()with no timeout settings, meaning requests and streaming responses can hang indefinitely if the backend stops responding or a connection drops mid-stream.This affects:
Impact
Users running agentic workloads (e.g. via API with tools like OpenClaw) may encounter silent hangs rather than fast failures when connectivity issues occur. This makes it harder to implement retry logic on the client side since the error is never returned.
Proposed Fix
Add a configurable timeout via environment variable (e.g.
MAPLE_REQUEST_TIMEOUT_SECS, defaulting to something reasonable like 300s for streaming). Apply it when constructing the reqwest client:For streaming specifically, a separate read/idle timeout may also be worth considering to handle cases where the server starts a response but stalls mid-stream.