fix: add default HTTP request timeout to prevent indefinite hangs#939
Closed
Alfredo Garcia (agarctfi) wants to merge 1 commit intotolik0/concurrent-source/add-block_simultaneous_readfrom
Conversation
Add default timeout of (30s connect, 300s read) to HttpClient.send_request(). When no explicit timeout is provided in request_kwargs, the default is injected before sending the request. This prevents requests.Session.send() from blocking indefinitely when a server stalls mid-response (e.g. after a 500 error retry). ConnectTimeout and ReadTimeout are already in TRANSIENT_EXCEPTIONS, so timeouts trigger automatic retries with exponential backoff. Co-Authored-By: alfredo.garcia@airbyte.io <freddy.garcia7.fg@gmail.com>
Contributor
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
👋 Greetings, Airbyte Team Member!Here are some helpful tips and reminders for your convenience. Testing This CDK VersionYou can test this version of the CDK using the following: # Run the CLI from this branch:
uvx 'git+https://github.com/airbytehq/airbyte-python-cdk.git@devin/1772836016-add-default-http-timeout#egg=airbyte-python-cdk[dev]' --help
# Update a connector to use the CDK from this branch ref:
cd airbyte-integrations/connectors/source-example
poe use-cdk-branch devin/1772836016-add-default-http-timeoutHelpful ResourcesPR Slash CommandsAirbyte Maintainers can execute the following slash commands on your PR:
|
Contributor
|
Closing this PR. The changes have been rebased into a new PR against |
5 tasks
6 tasks
Contributor
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.
fix: add default HTTP request timeout to prevent indefinite hangs
Summary
Adds a default timeout of (30s connect, 300s read) to
HttpClient.send_request(). Without this,requests.Session.send()blocks indefinitely when a server accepts a TCP connection but never responds or stalls mid-transfer.Context: An Intercom → Snowflake sync (Job 73656607) hung for 80+ minutes at 2.21M records after a 500 error. The CDK retried the request, but the subsequent HTTP call blocked forever with no timeout, no error, and no log output. This fix prevents that class of failure for all declarative connectors.
How it works:
HttpClient:_DEFAULT_CONNECT_TIMEOUT = 30,_DEFAULT_READ_TIMEOUT = 300send_request(), ifrequest_kwargsdoes not already contain a"timeout"key (after merging env settings), the default tuple is injectedConnectTimeoutandReadTimeoutare already in the CDK'sTRANSIENT_EXCEPTIONS, so timeouts trigger automatic retries with exponential backoff — no new error paths introducedNote: This PR targets the
tolik0/concurrent-source/add-block_simultaneous_readbranch (PR #870) because the affected connector is pinned to a dev image from that branch.Review & Testing Checklist for Human
timeoutinrequest_kwargs.ConnectTimeout/ReadTimeout(they're inTRANSIENT_EXCEPTIONS), but worth confirming with a real connector that a timeout → retry → success path works as expected and doesn't surface confusing user-facing errors.Notes
main). This PR applies the same fix on top of the feat: Add block_simultaneous_read with top-level stream_groups interface #870 feature branch.ConcurrentReadProcessorchanges for stuck-sync potential: the blocking/deferral logic is not the cause of the hang. The root cause is purely the missing HTTP timeout. However, the group-based blocking in feat: Add block_simultaneous_read with top-level stream_groups interface #870 does mean a hung stream blocks the entire group, making this timeout fix even more important.