Repository navigation
test: pyshark tests flake when another reaper collects tshark's exit status (TSharkCrashException, retcode 255) #2620
Description
Main's Unit Tests run 41382330109 (f9d5f0d1d) is red on Engines (PyShark), job 125076675677. In the Python 3.12 cell, test_engine_verbose_callback_1874_unit.py::PySharkVerboseTests::test_a_verbose_callback_is_called_with_every_frame failed with TSharkCrashException: TShark (pid 3394) seems to have crashed (retcode: 255). The other four cells passed the same test.
It is the same signature as #1534. asyncio logs Unknown child process pid 3394, will report returncode 255, which means something else in the process collected tshark's exit status before pyshark could. #1536 only retries inside the engine-agreement module, so every other pyshark test is still exposed.
Plan: find what reaps the child. Candidates are a waitpid(-1), a SIGCHLD handler, or a second child watcher, in pcapkit, the test support code or a plugin. Then fix it at the source and prove it by repeated runs. Add a shared retry only if the reaper turns out to be outside pcapkit's control. A skip is not acceptable.
Activity
test: rerun a PyShark extraction whose tshark asyncio lost (#2620)
JarryShaw commentedon Nov 2, 2026
Landed on
mainasfccd49dc7; it is test-only. The cause is CPython gh-87744, on 3.9–3.12. asyncio'sPopen.kill→poll()reaps an exited tshark beforeSafeChildWatchersees it, so pyshark reports retcode 255. Nothing in pcapkit reaps children.retry_reaped_tsharkreruns an extraction once, and only when asyncio logged that tshark's exit status as lost. All four test sites that spawn a real tshark use it, confirmed by a spy onasyncio.create_subprocess_exec. On 3.12 the CI PyShark cell went from 7/50 failures to 0/50. A Sonnet cross-review confirmed the diagnosis, and its call-site findings are folded in. The library-level fix for users is #2633.docs(changelog): fold NoPayload's move, family-base dispatch and the …
test: skip the lost-exit-status child on GraalPy, whose set_wakeup_fd…