SMOODEV-2513: Connect timeout for Python fetch SDK (parity with #88)#90
Open
brentrager wants to merge 1 commit into
Open
SMOODEV-2513: Connect timeout for Python fetch SDK (parity with #88)#90brentrager wants to merge 1 commit into
brentrager wants to merge 1 commit into
Conversation
Parity with Rust fetch#88. Adds optional connect_timeout_ms to TimeoutOptions. When set, only the connect phase is capped (via httpx.Timeout(whole, connect=...)) so black-holed connects fail fast instead of stalling until the whole-request timeout; the remaining phases keep timeout_ms. Default None = byte-identical current behavior. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
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
1 participant
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.
Problem
The Rust fetch SDK gained a bounded connect-phase timeout in #88 (SMOODEV-2498 / SMOODEV-2481): api-prime's ~16s stalls were fresh SYNs to dead pod IPs still lingering in a ClusterIP's iptables. Without a connect timeout, the client waits the full whole-request timeout on a black-holed connect. The Python SDK had no equivalent.
Solution
Add optional
connect_timeout_ms: float | None = NonetoTimeoutOptions. httpx supports per-phase timeouts natively, so when set we constructhttpx.Timeout(whole_s, connect=connect_s)— only the connect phase is capped while read/write/pool keeptimeout_ms. A black-holed connect now fails fast (surfaced as the SDK'sTimeoutError, sincehttpx.ConnectTimeoutsubclasseshttpx.TimeoutException) instead of hanging until the whole timeout.Default-off: when
connect_timeout_ms is Nonethe timeout construction is byte-identical to before (httpx.Timeout(timeout_seconds)) — existing callers are behavior-identical.Test
test_connect_timeout_fails_fast_on_black_holemirrors the Rustconnect_timeout_fails_fast_on_black_hole: a request to non-routablehttp://10.255.255.1:80/with a 500ms connect timeout and a 10x (5s) whole timeout must raise and return in well under 3s.poe lint/poe format:check/poe typecheckcleanpoe test: 127 passed🤖 Generated with Claude Code