| FazBrowse GitHub Viewer | Trending | | Home |
| Tools: [Download Repo ZIP] [Original HTTPS Page] |
The stdio interaction test's child only persisted its coverage data in coverage's atexit hook. On a slow Windows runner the interpreter teardown plus sqlite save can overrun the transport's termination grace, and the Job Object kill then silently destroys (or tears) the data file: every test passes but the 100% gate trips on _stdio_server.py's subprocess-only lines. Save the data explicitly before printing the clean-exit line instead. The test already synchronizes on that line, so once it has been observed the data is durably on disk and a late kill is harmless. A kill before the print now fails the stderr assertion loudly instead of tripping the coverage gate. The trailing lines are excluded (lax no cover): nothing measured can execute after the flush by construction.
There was a problem hiding this comment.
lgtm
Sorry, something went wrong.
|
This pull request is included in pre-release v2.0.0a2 |
Sorry, something went wrong.
| Back | FazBrowse Home | New Git URL |
Makes the stdio interaction test's subprocess flush its coverage data before printing the clean-exit line, so the transport's terminate escalation can no longer silently destroy the data file.
Motivation and Context
checks / test (3.10, locked, windows-latest) failed on #2838 with every test passing but the 100% gate tripping on tests\interaction\transports\_stdio_server.py at 52.17% — exactly the subprocess-only lines (failing job).
Root cause: the child only persisted its coverage data in coverage's atexit hook, which runs after the stdio-echo: clean exit print the test synchronizes on. The failing run's test took 12.40s ≈ 2.4s session + exactly the 10.0s PROCESS_TERMINATION_TIMEOUT the test monkeypatches — the child printed the line (test green), then didn't finish interpreter teardown + the sqlite save within the grace, and the Windows escalation (TerminateJobObject) killed it mid-save. A torn save leaves a valid-but-empty data file that coverage combine merges without a warning, which is why the failing run still combined the same 6 data files as passing runs.
This is the same race #2773 narrowed by raising the grace from 2s to 10s; the wider grace made it rarer, not impossible. Extracting this test's wall time from ~400 recent Windows CI job logs shows a smooth heavy tail — p50 3.3s, p99 ~7s, then 8.8s and 9.0s (passed, barely under the grace) and 12.4s (killed) — so any finite grace loses occasionally as long as the data write happens after the observable sync point.
The fix inverts the ordering instead: main() now stops and saves coverage before printing the clean-exit line. That makes the test's existing stderr assertion the durability barrier — once the parent has seen the line, the data is on disk and a late kill is harmless. A kill landing before the print now fails the stderr assertion loudly instead of tripping the coverage gate one step later.
Details that fall out of the ordering:
How Has This Been Tested?
Breaking Changes
None — test-support change only.
Types of changes
Checklist
Additional context
The import coverage at module top makes this test-support file depend on the dev environment even for the docstring's standalone python -m invocation; that's already true of the repo's dev venv everywhere this module is used, so it keeps imports-at-top rather than adding a guarded import plus more pragma machinery.
AI Disclaimer