Repository navigation
docs(concurrent-cdk): mark timeout_seconds as deprecated and ignored - #1208
Merged
Baz (bazarnov) merged 1 commit intoOct 6, 2026
Merged
Conversation
`ConcurrentSource.timeout_seconds` has not been read since the queue timeout it fed was removed, yet the docstring still promised the read stops when no record arrives within it. Document it as deprecated and ignored and drop the unread attribute. The parameter and `DEFAULT_TIMEOUT_SECONDS` stay for existing callers; the constant gets a comment saying it is only that parameter's default. The `PartitionEnqueuer` and `PartitionReader` docstrings also said the main thread waits for a timeout when a worker exception never reaches the queue. It blocks on the queue forever.
👋 Greetings, Airbyte Team Member!Here are some helpful tips and reminders for your convenience. 💡 Show Tips and TricksTesting 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@bazarnov/docs-concurrent-source-timeout-seconds#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 bazarnov/docs-concurrent-source-timeout-secondsPR Slash CommandsAirbyte Maintainers can execute the following slash commands on your PR:
|
Anatolii Yatsuk (tolik0)
approved these changes
Oct 6, 2026
Baz (bazarnov)
deleted the
bazarnov/docs-concurrent-source-timeout-seconds
branch
October 6, 2026 12:16
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.
Overview
👉 TL;DR: Corrects the docs for an old option that promised a sync would stop by itself when no data arrived for a while. The option has done nothing since 2024; it stays only so existing code that passes it keeps working.
Specifically,
ConcurrentSource.__init__now documentstimeout_secondsas deprecated and ignored, and the never-readself._timeout_secondsassignment is removed.timeout_secondsoncreate()and__init__()andDEFAULT_TIMEOUT_SECONDSstay in the public signature. Two worker docstrings that said the main thread waits for a timeout now say it blocks on the queue forever.Pairs with #1168:
Changes
concurrent_source.py: thetimeout_secondsdocstring says "Deprecated and ignored" instead of promising the read stops when no record arrives from the queue within it._consume_from_queueblocks on a barequeue.get(), so that promise has been false since Fix concurrent deadlock airbyte#34454.concurrent_source.py: dropself._timeout_seconds = timeout_seconds, the attribute's only occurrence in the repository.concurrent_source.py:DEFAULT_TIMEOUT_SECONDSgets a trailing comment saying it is only the default of the ignoredtimeout_seconds.partition_enqueuer.py,partition_reader.py: the docstrings no longer say the main thread waits for a timeout when a worker exception never reaches the queue; it blocks on the queue forever. Both lines were added by Fix concurrent deadlock airbyte#34454, the change that removed that timeout. Also fixes "when wrong" to "went wrong".Review Spotlight
Reviewers with limited time, please review first:
concurrent_source.py#L85-L99: the kept parameter, the new docstring line and the constructor body without the assignmentconcurrent_source.py#L145-L150: the barequeue.get()the old docstring contradictedRisks
timeout_secondssince Fix concurrent deadlock airbyte#34454 removedThrottledQueue, whoseget()applied the timeout. The signature is unchanged:timeout_seconds: int = DEFAULT_TIMEOUT_SECONDSoncreate()and__init__(),DEFAULT_TIMEOUT_SECONDS = 900._timeout_secondsattribute, which now raisesAttributeError. Readers found: 0.main:git grep -n _timeout_secondsreturns only the removed line.git grep -n -w timeout_secondsfinds no caller that passes it (the other hit is the unrelatedConnectorTestScenario.timeout_secondsfield);ConcurrentDeclarativeSourceandFileBasedSourcecallConcurrentSource.create()without it.master:git grep -n "\._timeout_seconds" origin/mastermatches onlysource-google-ads's ownRunAsThread._timeout_seconds, unrelated.git grep -n -E "ConcurrentSource\.create\(|ConcurrentSource\(" origin/master -- airbyte-integrations/connectorsfinds 1 direct caller,source-salesforce, which does not passtimeout_seconds.Test plan
No new test: nothing changes at runtime.
python -m pytest unit_tests/sources/concurrent_source unit_tests/sources/streams/concurrent unit_tests/sources/test_source_read.py unit_tests/sources/declarative/async_job/test_integration.py -q -p no:cacheprovidermain: 272 passedunit_tests/sources/declarative/test_concurrent_declarative_source.py86 passed (3test_read_with_concurrent_and_synchronous_streams*tests deselected, they can crash on the sqlite cache race in Cached parent stream with more than one partition corrupts the shared sqlite request cache under concurrent reads (no such table: responses,file is not a database,no more rows available) #1150);unit_tests/sources/file_based/test_file_based_scenarios.py253 passed.inspect.signatureon both refs:timeout_seconds: int = 900onConcurrentSource.createandConcurrentSource.__init__, andDEFAULT_TIMEOUT_SECONDS == 900.hasattr(source, "_timeout_seconds")on a source built withConcurrentSource.create(..., timeout_seconds=1)isTrueonmainandFalsehere.ruff format --check,ruff checkandmypy --config-file mypy.inionconcurrent_source.py,partition_enqueuer.pyandpartition_reader.py: clean.Design notes: why no queue watchdog or page-token guard
Show/Hide Content
timeout_secondsis not wired back up as a queue timeout:queue.gettimeout it fed, after sources died onqueue.Empty.ThreadPoolExecutorworkers are joined at interpreter exit, so after the main thread raises, the process stays alive until the platform heartbeat ends the attempt. Checked with a worker blocked on a socketrecvwith no timeout: the process was still alive 6 s after the main thread raised.AsyncJobOrchestratorpolls withtime.sleepand logs outside the queue, for up to the 60 min defaultpolling_job_timeout(24 h forsource-salesforceBulk). A queue timeout would fail those healthy syncs.The stall #1148 reports is an HTTP response that never finishes. #1168 bounds it at the request with default connect and read timeouts (layer 1).
A repeated-page-token guard (layer 3) is intentionally not added. Scroll APIs can return the same token on every page: Intercom does, and a custom paginator that stopped on a repeated token truncated its Companies stream to about 200 records (airbytehq/airbyte#70335). A cursor that never advances is ended with the manifest's
stop_condition, which sees the raw response.Part of #1148