Vito Sansevero
b8a045f127
On Windows py3.13 CI (PR #405) a one-file duplicate cleanup missed its 10 s WAIT. The test already waits on the job's own task; the 10 s bound acted as a deadline on disk-bound work. In the same 50 s window the following tests' setups took up to 9 s against 0.1-0.6 s around it while the test bodies stayed fast, which is consistent with a process-wide disk I/O stall on the runner rather than a lease, handle, executor or job stall (the log has no thread dump to show more). tests/disk_waits.py holds the one disk-bound hang guard (90 s per wait, under the 120 s per-test watchdog), shared with RESTORE_SECONDS (#382). Waits on find and cleanup job tasks in the duplicate-files tests use it; gates and server-state polls keep WAIT. The keeper-validation test turns the safety backup off, since it does not test backups.
17 lines
817 B
Python
17 lines
817 B
Python
"""Hang guards for waits on disk-bound work (tests only).
|
|
|
|
A test that waits for a job or handoff whose work is file and SQLite I/O
|
|
(a safety backup with fsync, a restore, hashing and unlinking files) waits
|
|
on that state; the ceiling below only ends a real hang. Hosted Windows
|
|
runners stall disk I/O for tens of seconds at a time: a restore took over
|
|
10 s (merge queue, #382), and on PR #405 every test setup in a 50 s window
|
|
took up to 9 s against 0.1-0.6 s around it while the test bodies stayed
|
|
fast, so a one-file duplicate cleanup missed a 10 s bound (#409).
|
|
|
|
The ceiling is per wait and stays under the suite's 120 s per-test hang
|
|
watchdog. A test with several such waits in a row can reach the watchdog
|
|
first; either way a real hang fails, the watchdog with every thread's stack.
|
|
"""
|
|
|
|
DISK_BOUND_SECONDS = 90
|