[JarryShaw]

• Searched for similar pull requests
• Followed the coding style (make pylint, make mypy, make isort) — they lint pcapkit/, which is untouched
• make test passes, and a test case covers the change (selections only, listed below)
• Changelog entry: N/A — centralised in docs(changelog): shared 1.5.0 changelog — long-lived, merges last (#610, #616, #617, #618, #620) #657

What is the purpose of your pull request?

• test — tests only

---

Description of your pull request and other information

NoEOFOverAGrowingFileStopsAtWhatIsThere appended its sixth frame after time.sleep(0.6). On a loaded runner the extractor reached end of stream later than that, read six frames, and failed (job 114144569834).

The child now takes five frames with next(), wraps pcapkit.foundation.extraction.warn, and appends the sixth frame inside the second EOF reached announcement. At that point the extractor has met end of stream, retried, and met it again at the same position. The test also asserts both ends of stream were seen on the 430-byte file and that the append happened. The first announcement is deliberately not the trigger: its retry exists for a paused capture, so a frame appended there is read. Measured: that variant gets [1, 2, 3, 4, 5, 6]. The child bound and the SENTINEL protocol are unchanged.

Fails when the rule is broken. On a18846c8f (#639's parent) and 6c3d1b0d9, the child reads frame 6 and then times out at 30s. On scratch mutants that follow by file size or add a 0.2s grace, it gets [1, 2, 3, 4, 5, 6]. The old timer test passed the grace mutant 5/5.

Ran (Python 3.14): the case 30/30 under 32 CPU burners on 16 cores (load ~35); tests/foundation/test_extraction_no_eof.py 11 passed; tests/project/test_per_class_import_guard.py and test_isort_clean.py pass.

Closes #1583

[JarryShaw]

Verdict: GOOD TO GO at 6dc53b8db. This was a Sonnet cross-review; the author ran Opus. Only tests/foundation/test_extraction_no_eof.py changes.

• It reproduces the test: the no_eof growing-file test races a 0.6 s timer and fails on a slow runner #1583 failure and is immune to it. With time.sleep(0.5) injected into every Extractor.__next__ to emulate a slow runner, the old test fails with [1, 2, 3, 4, 5, 6], the exact CI error, and the new one passes. Under 32 CPU burners on 16 cores the old test also passed 12 of 12, which is why a contention run alone proves little.
• It still pins the rule:
  • keep reading while the file is longer than the position: [1, 2, 3, 4, 5, 6];
  • add a 0.2 s grace period: the same failure;
  • pre-fix 6c3d1b0d9: hangs and fails at the 30 s child bound.
• The docstring's sharper wording matches the code. Appending at the 1st EOF announcement is followed by the retry; at the 2nd, it isn't. That agrees with the no_eof docstring (extraction.py:1132-1140) and the 1.5.0 changelog.
• Coupling to warn is acceptable. EOF is detected in prepare (utilities/decorators.py:269-279) through seek/tell, never through a read returning b'', so no cleaner seam exists. Rewording the warning makes the test fail loudly (no append: []), though not with a pointer to the seam (nit).
• Results: 20 of 20 under contention, and the whole module passes (11). The mkdtemp leak is gone.

[github-actions]

Coverage: 89.63% (unit tier, Python 3.14, 6dc53b8db, Unit Tests run success)

Package	Statements	Missed	Branches	Partial	Cover
pcapkit (top level)	104	4	20	4	93.55%
pcapkit/const	18858	957	2366	871	91.03%
pcapkit/corekit	2334	67	746	35	96.43%
pcapkit/dumpkit	275	3	100	3	98.40%
pcapkit/foundation	2792	154	984	42	93.43%
pcapkit/interface	138	7	52	5	93.68%
pcapkit/protocols	16988	230	4540	191	98.02%
pcapkit/toolkit	708	96	234	6	85.35%
pcapkit/utilities	431	4	124	4	98.56%
pcapkit/vendor	4409	2342	1006	157	43.25%

Per-file detail: the coverage-html artifact of this run.