Branch: refs/heads/main
Home: https://github.com/WebKit/WebKit
Commit: 92641830324a1fd532b6782aaf82e52f6ffb6883
https://github.com/WebKit/WebKit/commit/92641830324a1fd532b6782aaf82e52f6ffb6883
Author: Claudio Saavedra <[email protected]>
Date: 2026-09-10 (Thu, 10 Sep 2026)
Changed paths:
M Tools/Scripts/webkitpy/webdriver_tests/pytest_runner.py
Log Message:
-----------
[WebDriver] pytest-timeout's SIGALRM can wedge the asyncio loop and hang the
run
https://bugs.webkit.org/show_bug.cgi?id=322171
Reviewed by Carlos Alberto Lopez Perez.
pytest-timeout raises from its SIGALRM handler wherever the alarm lands. When
that is inside asyncio's scheduler, for instance while Future.set_result() is
queueing the wake-up of the task awaiting it, the future is marked done but the
wake-up is never scheduled. asyncio swallows the exception as "Exception in
callback", the test task is parked for good, and the loop keeps servicing the
websockets keepalive until someone kills the bot. Every run of the BiDi tests
expected to time out goes through this path.
Wrap the handler pytest-timeout installs so that, while an event loop is
running, the alarm is only delivered from the selector the idle loop is blocked
in, where the exception propagates cleanly out of run_until_complete(). Anywhere
else inside the loop it is re-armed a few milliseconds later instead.
Also match the timeout message pytest-timeout 2.4.0 produces, which has been
making unexpected timeouts show up as failures since the bump.
* Tools/Scripts/webkitpy/webdriver_tests/pytest_runner.py:
(SubtestResultRecorder._was_timeout):
(TimeoutSignalHandler):
(TimeoutSignalHandler.pytest_timeout_set_timer):
(TimeoutSignalHandler._should_defer_timeout):
(run):
Canonical link: https://commits.webkit.org/320815@main
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
