fix(system): add configurable timeout to HTTP client#205
Open
efe-arv wants to merge 1 commit intovxcontrol:masterfrom
Open
fix(system): add configurable timeout to HTTP client#205efe-arv wants to merge 1 commit intovxcontrol:masterfrom
efe-arv wants to merge 1 commit intovxcontrol:masterfrom
Conversation
GetHTTPClient creates http.Client without a Timeout field, causing goroutines to hang indefinitely when an external API (LLM provider, search tool, etc.) stops responding. This affects all 17 call sites across every provider (OpenAI, Anthropic, Gemini, DeepSeek, Kimi, Qwen, GLM, Ollama, custom) and all search tools (Tavily, DuckDuckGo, Sploitus, Perplexity, Google, Traversaal, SearxNG). Changes: - Add HTTP_CLIENT_TIMEOUT env var (default: 600s / 10 minutes) - Set Timeout on all http.Client instances returned by GetHTTPClient - When cfg is nil, return a client with the default timeout instead of http.DefaultClient (which has no timeout) - Add 5 unit tests covering default, custom, zero, nil, and proxy timeout scenarios - Document the new env var in .env.example Relates to vxcontrol#176 (context canceled on agent delegation), which identified the missing HTTP client timeout as a contributing factor.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
GetHTTPClientinsystem/utils.gocreateshttp.Clientinstances without aTimeoutfield. When an external API (LLM provider, search tool, scraper, etc.) stops responding or hangs, the calling goroutine blocks indefinitely — leading to goroutine leaks and eventual resource exhaustion.This affects all 17 call sites across the codebase:
Changes
backend/pkg/config/config.goHTTPClientTimeoutconfig field (HTTP_CLIENT_TIMEOUTenv var, default 600s)backend/pkg/system/utils.goTimeouton allhttp.Clientinstances; use default timeout for nil configbackend/pkg/system/utils_test.go.env.exampleHTTP_CLIENT_TIMEOUTenv varDesign Decisions
HTTP_CLIENT_TIMEOUT=0falls back to the 10-minute default rather than disabling timeouts entirely, preventing accidental infinite hangs.http.DefaultClient(no timeout); now returns a client with the default timeout.Relation to Existing Issues
This is a contributing factor to #176 (agent delegation context canceled). While #195 addresses the detached command context issue, the underlying HTTP client still has no timeout — meaning a hanging LLM API call will block the goroutine forever even after the context fix.
Testing
Added 5 unit tests:
TestGetHTTPClient_NilConfig— nil config returns client with default timeoutTestGetHTTPClient_DefaultTimeout— config with default value (600s)TestGetHTTPClient_CustomTimeout— config with custom value (120s)TestGetHTTPClient_ZeroTimeoutUsesDefault— zero falls back to defaultTestGetHTTPClient_TimeoutWithProxy— timeout applies with proxy configuredVerification
GetHTTPClient→ automatically get timeout).env.exampleupdated with documentation