test: consolidate polling into a single shared helper and deflake tests#920
Open
vdusek wants to merge 4 commits into
Open
test: consolidate polling into a single shared helper and deflake tests#920vdusek wants to merge 4 commits into
vdusek wants to merge 4 commits into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #920 +/- ##
=======================================
Coverage 86.94% 86.94%
=======================================
Files 48 48
Lines 2942 2942
=======================================
Hits 2558 2558
Misses 384 384
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Make call_with_exp_backoff and poll_until_condition generic and consistent so the same two helpers can be shared across apify-sdk-python, crawlee-python and apify-client-python: - call_with_exp_backoff no longer takes rq_access_mode. It now takes an optional condition (default: truthy) and retries fn until the condition holds, returning the last result. The Apify RQ single/shared distinction moves to the call sites via max_retries (0 = call once / single mode, 5 = retry / shared mode). - poll_until_condition gains the same condition default and now accepts both sync and async callables (so it can poll plain values too). - Both helpers accept sync or async fn via a small _maybe_await helper, typed with overloads so the return type is preserved. All ~36 call sites in test_request_queue.py are refactored accordingly.
Replace the two integration polling helpers with a single poll_until_condition in a shared tests/_utils.py, matching the helper in apify-client-python (with backoff_factor covering the exponential-backoff use case). Use it across integration, e2e, and unit tests instead of hand-rolled retry loops and fixed sleeps, and fix the flaky webhook e2e test by keeping the client run alive briefly after add_webhook so the run-succeeded event cannot outrun the webhook registration.
3052131 to
fffc7eb
Compare
…run, bound webhook wait) - Add an rq_poll_timeout fixture deriving the single/shared polling timeout from the request_queue_apify param, replacing the derivation block that was copy-pasted into all 20 request queue tests. - Extract the byte-identical get_run closure in test_actor_charge.py into a module-level _get_run helper used via functools.partial. - Bound the webhook server Actor's wait loop (5s server timeout, 300s deadline) so a webhook that never propagates fails the test quickly with an empty WEBHOOK_BODY and a clear message instead of blocking until the run timeout.
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.
Summary
Started as a generalization of the two integration polling helpers, and grew into the SDK counterpart of apify/apify-client-python#844: a single shared polling helper used across the whole test suite.
Changes:
tests/_utils.pywith a singlepoll_until_conditionhelper — identical to the one inapify-client-python(chore(deps): update codecov/codecov-action action to v6 #844): polls a sync-or-async callable at a constant interval until a condition holds or a wall-clock timeout expires, with an optionalbackoff_factorthat multiplies the interval after each poll. This subsumes the formercall_with_exp_backoff(backoff_factor=2) and the "call once" single-RQ-mode case (timeout=0). The duplicatedgenerate_unique_resource_name(integration + e2e copies) moves there too;tests/integration/_utils.pyandtests/e2e/_utils.pyare removed.call_with_exp_backoffcall sites intest_request_queue.pytopoll_until_condition(timeout=30,backoff_factor=2for shared mode ≈ the former exponential backoff;timeout=0for single mode). Pre-existingpoll_until_conditioncall sites get their former defaults (timeout=60,poll_interval=5) passed explicitly.test_actor_adds_webhook_and_receives_evente2e test (failing CI run): the client Actor exited ~170 ms after registering the ad-hoc webhook, so the platform could process the run-succeeded event before the webhook propagated, leaving the server Actor blocked until its run timeout. The client now stays alive 5 s afteradd_webhook, and the unboundedINITIALIZEDstartup polling loop is replaced withpoll_until_condition(timeout=300, growing interval). Replaces test: fix flaky webhook E2E test #930.retry_counterloops intest_actor_charge.py(4×) withpoll_until_condition.test_actor_lifecycle,test_actor_key_value_store,test_apify_event_manager) with condition polling where the test waits for something to happen — faster on the happy path and robust under xdist load.Fixed sleeps that are semantically required are intentionally left as-is: negative checks ("event must NOT fire"), mtime-granularity checks in
test_apify_storages, simulated latency, and sleeps inside Actormain_funcbodies (which are serialized and deployed to the platform, where the helper is not available).Verification: lint, type-check, and the full unit suite pass; the three touched unit test files pass 10/10 repeated runs. Integration/e2e tests require a platform token and will be verified by CI.