Repository navigation
Conversation
test_catalog_wait_respects_provisioning_deadline raced a fixed 0.1s asyncio.wait_for against provisioning reaching the catalog fetch, then asserted catalog.started was set. On slower CI the reconcile path often did not reach the fetch within 100ms, so the assertion failed intermittently (seen repeatedly across unrelated PRs). Wait for the fetch to be in flight (catalog.started) before applying the deadline, so the timeout lands on the blocked fetch rather than on the work leading up to it. The deadline then fires deterministically because the fetch is held open, independent of machine speed. Behavior under test is unchanged; only the timing coupling is removed.
Let the deadline cancel the provisioning task (as a real one would) rather than shielding it, so the cache assertions run after the cancellation and keep verifying that a cancelled deadline does not record a failure or partial members. Determinism is preserved: the test still waits for the fetch to be in flight before applying the deadline.
Contributor
|
bugbot run |
There was a problem hiding this comment.
🟢 Approval recommended
No active review issues were identified for the test-only catalog-fetch synchronization and task-cleanup changes.
No open issues 🎉
What changed in this PR
This test-only change removes the timing race between provisioning startup and the catalog-fetch deadline, making the test less sensitive to slow CI without changing production behavior.
Changes:
- Wait for the catalog fetch to start before applying the provisioning timeout.
- Preserve cancellation and cache-health assertions.
- Cancel and await the provisioning task in a
finallyblock for reliable cleanup.
| File | Description |
|---|---|
tests/test_apps/test_gpu_catalog.py |
Synchronizes the deadline test with fetch startup and adds task cleanup. |
Review effort: Balanced
KAJdev
approved these changes
Nov 9, 2026
This branch has not been deployed
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.
What
test_catalog_wait_respects_provisioning_deadline(tests/test_apps/test_gpu_catalog.py) raced a fixedasyncio.wait_for(provision(...), timeout=0.1)against provisioning actually reaching the catalog fetch, then assertedcatalog.started.is_set(). On slower CI (notably the 3.10 job) the reconcile path often did not reach the HTTP fetch within 100ms, so the fetch never started and the assertion failed intermittently. It failed repeatedly across unrelated PRs over the past days.Fix
Wait for the fetch to be in flight (
catalog.started) before applying the deadline, so the timeout lands on the blocked fetch rather than on the work leading up to it. The fetch is held open (release cleared), so the deadline fires deterministically regardless of machine speed. The behavior under test is unchanged; only the timing coupling is removed. This mirrors the already-stable sibling testtest_catalog_wait_keeps_event_loop_responsive.Test-only change.
Test plan
assert catalog.started.is_set(), the new logic passes.test_gpu_catalog.pygreen on both (36 passed each).