test: pass timeout=200 to ServiceInfo-request timeout tests#1677
Merged
Conversation
Three tests were each taking ~3 seconds because they relied on the default 3000ms ServiceInfo request timeout to lapse: - test_request_timeout (tests/services/test_info.py) - test_async_request_timeout (tests/test_asyncio.py) - test_unicast_flag_if_requested (tests/services/test_info.py) Pass `timeout=200` explicitly so the request fails over in ~0.2s instead of ~3s. The first two assert the elapsed time is close to the requested timeout; the assertion bound moves from `< 3000 + 1000` to `< 200 + 1000` so the property under test (timeout returns roughly when asked, plus a slack for scheduler overhead) is preserved. Combined wall time across the three goes from ~9s to ~0.75s.
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #1677 +/- ##
=======================================
Coverage 99.76% 99.76%
=======================================
Files 33 33
Lines 3401 3401
Branches 461 461
=======================================
Hits 3393 3393
Misses 5 5
Partials 3 3 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
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
1 participant
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
Three tests were each taking ~3 seconds because they relied on
the default 3000ms
ServiceInforequest timeout to lapse:test_request_timeout(tests/services/test_info.py)test_async_request_timeout(tests/test_asyncio.py)test_unicast_flag_if_requested(tests/services/test_info.py)Pass
timeout=200explicitly so the request fails over in ~0.2sinstead of ~3s.
Details
requested timeout — the property is "the timeout returns
roughly when asked, plus slack for scheduler overhead." The
assertion bound moves from
< 3000 + 1000to< 200 + 1000so the property is preserved at the new (smaller) timeout.
test_unicast_flag_if_requestedonly cares that every outgoingquestion has
question.unicastset; the timeout value isirrelevant to what it pins.
Combined wall time across the three goes from ~9s to ~0.75s.
Two other 3.01s tests in the same family
(
test_we_try_four_times_with_random_delay,test_get_info_suppressed_by_question_history) are notincluded here — they encode assumptions about retry counts /
question-history windows that are tied to the production timing
constants and need a separate fix.
Test plan
poetry run pytest tests/services/test_info.py::test_request_timeout tests/services/test_info.py::test_unicast_flag_if_requested tests/test_asyncio.py::test_async_request_timeoutpasses in 0.75s combined (was ~9s).