You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
test: the no_eof growing-file test races a 0.6 s timer and fails on a slow runner #1583
tests/foundation/test_extraction_no_eof.py::NoEOFOverAGrowingFileStopsAtWhatIsThere::test_a_file_appended_to_after_the_read_yields_only_what_was_there is a timing race. It failed on #1575's Python 3.14 leg (job 114144569834, run 38027859408) with AssertionError: [1, 2, 3, 4, 5, 6]. That PR doesn't touch extraction.
Cause: the test (:343-383) writes five frames, starts a thread that appends the sixth after time.sleep(0.6), and asserts that the extractor has already reached end of file by then. On a loaded runner, opening the extractor and reading five frames can take longer than 0.6 s; that leg's unit tests took 9m45s. The append then lands first and the extractor reads all six. My inference, not measured: #1560 moved part of the TCP/UDP registry import cost into the first extraction, which shrinks the margin.
Expected: a deterministic test of the same rule: a seekable file that is appended to after the reader has hit end of file is not followed. The append should be sequenced on an event, for example once the reader reports end of file or after five frames have been consumed, not on a timer. It should pass under CPU contention.
Activity
test(foundation): sequence the no_eof growing-file append on end of s…