Intermittent deterministic-test failure on Windows
During extended regression testing, this unchanged upstream test intermittently fails and then leaves its pytest process running:
uv run pytest -q tests/unit/runtime/test_device_lock.py::test_pending_reservation_is_served_with_original_fifo_position_after_claim
Confirmed independently on clean upstream 086078819209c7139d6f833cfdc6d5cc80d9f19a, Windows, Python 3.12.14, committed lockfile. Both passing and failing isolated runs were observed; no Android device or model credentials are required.
Sanitized failing output:
tests/unit/runtime/test_device_lock.py:248
assert claimed_acquired.wait(timeout=2.0)
E assert False
1 failed in 2.54s
The process did not exit by an external 10-second deadline and its owned test process tree was terminated. A passing upstream run reported 1 passed in 0.80s. The complete device-lock test module also passed once (17 passed in 1.83s), so this is not a consistently failing assertion.
The test starts two non-daemon threads that call blocking acquire(). If the claimed-ticket assertion fails, later releases and joins are bypassed. This explains why a failed assertion can leave a test process hanging. The reason the expected ticket does not acquire within two seconds is not yet established; this report does not assume that increasing the timeout fixes the ordering behavior.
Suggested investigation: capture queued ticket names/order and lock ownership on failure, determine whether the wait is scheduling-related or an ordering defect, and ensure cleanup releases/joins workers even when assertions fail. Both the tested lock implementation and this test are unchanged by #39/#42. This was reproduced on the upstream baseline as well as a local combined validation checkout.
No private screenshots or device traces are attached.
Intermittent deterministic-test failure on Windows
During extended regression testing, this unchanged upstream test intermittently fails and then leaves its pytest process running:
Confirmed independently on clean upstream
086078819209c7139d6f833cfdc6d5cc80d9f19a, Windows, Python 3.12.14, committed lockfile. Both passing and failing isolated runs were observed; no Android device or model credentials are required.Sanitized failing output:
The process did not exit by an external 10-second deadline and its owned test process tree was terminated. A passing upstream run reported
1 passed in 0.80s. The complete device-lock test module also passed once (17 passed in 1.83s), so this is not a consistently failing assertion.The test starts two non-daemon threads that call blocking
acquire(). If the claimed-ticket assertion fails, later releases and joins are bypassed. This explains why a failed assertion can leave a test process hanging. The reason the expected ticket does not acquire within two seconds is not yet established; this report does not assume that increasing the timeout fixes the ordering behavior.Suggested investigation: capture queued ticket names/order and lock ownership on failure, determine whether the wait is scheduling-related or an ordering defect, and ensure cleanup releases/joins workers even when assertions fail. Both the tested lock implementation and this test are unchanged by #39/#42. This was reproduced on the upstream baseline as well as a local combined validation checkout.
No private screenshots or device traces are attached.