You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
test: deflake integration tests by polling instead of fixed sleeps (#844)
## Summary
Started as a fix for [this flaky CI
run](https://github.com/apify/apify-client-python/actions/runs/26818252886/job/79065522664)
of `test_request_queue_unlock_requests[sync]` (`assert 2 == 3` on
`unlocked_count`, caused by replication lag between `list_and_lock_head`
and `unlock_requests`), and grew into deflaking the integration test
suite as a whole.
**Changes:**
- Add a `poll_until_condition` helper to `tests/integration/_utils.py`:
polls a sync-or-async callable at a constant interval until a condition
holds or a wall-clock timeout expires. An optional `backoff_factor`
multiplies the interval after each poll, for highly variable waits (e.g.
Actor run container startup) where a growing delay covers a long timeout
with few calls.
- Fix the flaky unlock test by polling `list_head` until the locked IDs
disappear from the queue head before unlocking.
- Replace all hand-rolled `for _ in range(5): sleep(1); read; break`
polling loops (10×) and single fixed `sleep(1)` waits (26×) across the
request queue, dataset, key-value store, and run integration tests with
`poll_until_condition`. This makes the tests both faster on the happy
path (no unconditional sleep) and more robust under load (polls until
the timeout instead of hoping 1 s is enough).
- Generalize `maybe_await` to accept any awaitable.
The three `iterate_keys` sleeps in the KVS tests are intentionally left
as-is: draining an iterator per attempt wants attempt-count semantics
(like `collect_iterate_until_present`), not a wall-clock deadline.
Follow-up to #786.
0 commit comments