Skip to content

test(apps): de-flake catalog provisioning deadline test - #703

Open
deanq wants to merge 5 commits into
mainfrom
deanq/flaky-catalog-deadline-test
Open

deanq wants to merge 5 commits into
mainfrom
deanq/flaky-catalog-deadline-test

Conversation

@deanq

@deanq deanq commented Nov 9, 2026

Copy link
Copy Markdown
Member

What

test_catalog_wait_respects_provisioning_deadline (tests/test_apps/test_gpu_catalog.py) raced a fixed asyncio.wait_for(provision(...), timeout=0.1) against provisioning actually reaching the catalog fetch, then asserted catalog.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 test test_catalog_wait_keeps_event_loop_responsive.

Test-only change.

Test plan

  • Reproduced the flake deterministically by injecting a 0.25s pre-fetch delay (simulating slow CI): the old logic fails assert catalog.started.is_set(), the new logic passes.
  • Fixed test run on Python 3.10 and 3.13; reconcile variant stressed 40x on 3.10, all green.
  • Full test_gpu_catalog.py green on both (36 passed each).
  • Full suite via the pre-commit quality gate: 2773 passed.

deanq added 2 commits November 9, 2026 08:11
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.
@celine-runpod

Copy link
Copy Markdown
Contributor

bugbot run

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

🟢 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 finally block 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

This branch has not been deployed

No deployments
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.

4 participants