Repository navigation
test(api): give the voice relay tests one named hang guard instead of a one-second wait - #226
Merged
Merged
Conversation
… a one-second wait Signed-off-by: L4XB <lukas.buck@e-mail.de>
Member
Author
|
I have read and agree to the SixSentences CLA v1.0. |
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.
Closes #152.
Summary
The voice-relay tests waited one or two seconds for the relay task to finish, for example
task.cancel()followed byawait asyncio.wait_for(task, 1). On the cancellation paths that second has to cover_Relay.run's shielded cleanup: cancelling and gathering four tasks, closing the provider,conservative_finish,on_closedand closing the browser socket. On a runner at about half speed it did not, andtest_cancel_closes_upstream_before_terminal_callback_and_retains_pending_costfailed on PR #147, which did not touch the relay.The file now has one constant,
HANG_GUARD_SECONDS = 10, with a comment that says what it is for: it only turns a hang into a failure. All 22 waits in the file use it. That covers the 14 terminalwait_for(task, …)calls the issue lists, the waits onharness.start(...), the waits on thewrite_started/first_startedevents and thegather, and the default of theuntil()polling helper, which had the same 2-second guard.Is any of them asserting latency? No. The tests that care about timing pass their deadlines to the relay through
RelayLimits(meter_timeout_seconds=0.05)or0.3, and the relay enforces those itself. Those values are unchanged. Thewait_foraround them only stops a hung test.Behavior and compatibility
services/api/tests/test_voice_relay.py, plus the refreshedCOMMUNITY_EXPORT_MANIFEST.jsonentry for that file.Validation
uv run --frozen --extra dev pytest tests/test_voice_relay.py -q(inservices/api): 63 passed.ruff checkandruff format --checkon the changed file: clean.python scripts/audit_community_export.py .: passed (422 files, 402 HTTP operations, 1 WebSocket, 90 tables).python3 .github/scripts/check_dco.py --base <main> --head <head> --pull-request-author L4XB: DCO sign-offs validated.Review boundaries
Only test timeouts change. Engine, worker, migrations, web app, browser extension, Companion and self-hosting are unaffected.
Source-release hygiene
No data is committed.
CHANGELOG.mdhas an entry under Unreleased → Fixed. The commit is signed and carries my DCO sign-off, and the CLA acceptance sentence follows as a standalone comment.Visual evidence
None (no UI change).