Skip to content

feat: add configurable timeouts and connection pooling for upstream requests#21

Open
bianbiandashen wants to merge 1 commit into
runta-dev:mainfrom
bianbiandashen:feat/proxy-timeout-config
Open

feat: add configurable timeouts and connection pooling for upstream requests#21
bianbiandashen wants to merge 1 commit into
runta-dev:mainfrom
bianbiandashen:feat/proxy-timeout-config

Conversation

@bianbiandashen

Copy link
Copy Markdown
Contributor

Summary

Add HTTP client timeout and connection pool configuration to prevent resource exhaustion when upstream LLM APIs are slow or unresponsive.

Problem

The current implementation uses reqwest's default settings with no explicit timeout configuration. If an upstream API (OpenAI/Anthropic) becomes slow or unresponsive:

  • Connections may hang indefinitely
  • Connection pool can be exhausted
  • The proxy becomes unresponsive to new requests

Solution

Add configurable timeout and connection pool settings in the [upstream] section:

Option Default Description
connect_timeout_secs 30 TCP connection establishment timeout
request_timeout_secs 300 Full request/response cycle timeout
pool_idle_timeout_secs 90 Idle connection time-to-live
pool_max_idle_per_host 32 Max idle connections per upstream host

The 5-minute request timeout default accommodates long-running LLM completions while still protecting against hung connections.

Example Configuration

[upstream]
base_url = "https://api.openai.com"
connect_timeout_secs = 30
request_timeout_secs = 300
pool_idle_timeout_secs = 90
pool_max_idle_per_host = 32

Changes

  • src/config.rs: Add timeout fields to UpstreamConfig with default values
  • src/proxy.rs: Add ClientConfig struct and with_config() constructor
  • src/lib.rs: Wire configuration through AppState::from_config()
  • clawshell.example.toml: Document new configuration options

Test Plan

  • New unit tests for ClientConfig default values
  • New unit tests for ProxyClient::with_config()
  • Verified backward compatibility (defaults match previous behavior)
  • All existing tests pass

…equests

Add HTTP client timeout and connection pool configuration to prevent
resource exhaustion when upstream LLM APIs are slow or unresponsive.

Configuration options (in [upstream] section):
- connect_timeout_secs: TCP connection timeout (default: 30s)
- request_timeout_secs: Full request/response timeout (default: 300s)
- pool_idle_timeout_secs: Idle connection TTL (default: 90s)
- pool_max_idle_per_host: Max idle connections per host (default: 32)

The default request timeout of 5 minutes accommodates long-running LLM
completions while still providing protection against hung connections.

Changes:
- config.rs: Add timeout fields to UpstreamConfig with sensible defaults
- proxy.rs: Add ClientConfig struct and with_config() constructor
- lib.rs: Wire up configuration in AppState::from_config()
- clawshell.example.toml: Document new configuration options
Comment thread src/config.rs
/// Default: 30 seconds.
#[serde(default = "default_connect_timeout_secs")]
pub connect_timeout_secs: u64,

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to use std::time::Duration here?

Comment thread src/config.rs
/// to accommodate long-running completions.
/// Default: 300 seconds (5 minutes).
#[serde(default = "default_request_timeout_secs")]
pub request_timeout_secs: u64,

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to use std::time::Duration here?

Comment thread src/config.rs
/// longer than this duration will be closed.
/// Default: 90 seconds.
#[serde(default = "default_pool_idle_timeout_secs")]
pub pool_idle_timeout_secs: u64,

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to use std::time::Duration here?

Comment thread src/config.rs
/// Maximum number of idle connections per host in the connection pool.
/// Default: 32.
#[serde(default = "default_pool_max_idle_per_host")]
pub pool_max_idle_per_host: usize,

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it make sense to use std::time::Duration here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants