test(vendor): re-resolve VendorRuntimeWarning fresh per generation (#985)

[JarryShaw]

• Searched for similar pull requests (ci(tests): add a plain-unittest leg to catch conftest-masked ordering defects #984 adds a unittest-ordering CI leg that excludes tests/vendor for this exact defect; nothing else fixes this file)
• Followed the coding style — make pylint/mypy/isort don't target tests/, N/A here
• make test passes — not run: pytest's conftest masks this defect class, and the full suite OOMs locally. Verified instead with plain unittest discover -s tests/vendor, per test(vendor): a stale warning-class generation makes the snapshot-restore assertion order-dependent #985/test: three modules pass alone but fail together, and pytest reports it green #981
• 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

Fixes #985. test_vendor_snapshot_restore_unit.py bound VendorRuntimeWarning at module level —
whatever generation was live at import time. Under plain unittest over tests/vendor (no
conftest), a sibling module purges+reimports pcapkit mid-run, minting a new class generation
(same skew as #981). assertWarnsRegex then compares against the stale generation while the
crawler raises the current one, so it reports "not triggered" though the warning is on stderr.

Fix: resolve VendorRuntimeWarning in setUp() via importlib.import_module, alongside the
vendor_main/Vendor pair setUp already re-resolves per test — same pattern as
RegistrationGateTests.setUp() in tests/test_base_class_contract.py (#984).

Red: unittest discover -s tests/vendor → AssertionError: VendorRuntimeWarning not triggered.
Green: same command → Ran 118 tests in 82.933s / OK. Alone: Ran 4 tests in 0.774s / OK.

[JarryShaw]

GOOD TO GO at f03f1d551 — opus cross-review. One prose correction going in on top, and it corrects a
claim I made as well as the docstring's.

assertWarnsRegex does not match by class identity. The docstring says it does; I checked the stdlib
this venv runs and the rule is isinstance(w, self.expected) — subclass semantics. The conclusion
survives for a reason worth stating precisely: the two generations are mutually unrelated, issubclass
false in both directions, so an isinstance test against the stale class rejects an instance of the
fresh one. Same outcome an identity check would give, different mechanism — and a reader who believes it is
identity will mis-predict what a genuine subclass does. A worker is fixing that one sentence; everything
else in the docstring was independently checked and is true.

The fix is complete, and it was the only instance in the directory. git grep -nE "^(from|import) pcapkit" origin/main -- tests/vendor/ returns exactly one line across all 14 modules — this file's.
So the fix makes it converge on its 13 siblings rather than patch one of three. No setUpClass, no
tearDownClass, no class-body state, so nothing is left to reintroduce the skew.

Red and green reproduced independently, Ran 118 tests in 81.159s ... FAILED (failures=1) → 81.348s ... OK, with the same single named failure.

The order dependence is now measured rather than assumed, and it is tighter than I had framed it:

order on main	result
…snapshot_restore_unit alone	Ran 4 … OK
test_vendor_dest_path_unit then …snapshot_restore_unit	Ran 8 … FAILED
…snapshot_restore_unit then test_vendor_dest_path_unit	Ran 8 … OK

The binding is captured at import; the assertion fails iff a purging sibling's test runs first.
…snapshot_restore_unit sorts last of the 14, behind all 8 purgers, so discover is always red —
which is exactly why "it passes alone" was never evidence of health. Eight modules, ten purge sites.

A correction to my own brief: I wrote that purge_modules "must be ('pcapkit',)". All ten real call
sites use ['pcapkit'], a list, which is an equally valid Iterable[str]. The trap is only the bare
string. I was right about the mechanism and wrong about this repo's spelling.

On whether this should wait for the broader fix: it should not, and the argument is better than "it is
small". Moving reconciliation into runner-neutral tests/_support.py would mask the skew — the test
would still bind a stale class and still depend on something external restoring the module table. This
removes the coupling, so it holds under any runner, including one nobody has written. The broader change
still stands on its own merits for tests/corekit/test_sentinels_housing_unit.py (9 module-level bindings),
tests/test_base_class_contract.py (7) and tests/corekit/test_sentinel_exports_unit.py (5), which cannot
sensibly be fixed one binding at a time.

One residual it flagged, non-blocking: run() warns with the class bound in
pcapkit/vendor/__main__.py's namespace while setUp resolves from pcapkit.utilities.warnings. They
agree only because purge_modules(['pcapkit']) drops the subtree atomically. self.vendor_main. VendorRuntimeWarning would be strictly tighter and two lines shorter. Nothing in the repo purges a
narrower pcapkit.utilities prefix today, so I am not asking for it.

UNVERIFIED: pytest on this branch (deliberately — the conftest fixture masks this class, so pytest is not a
valid instrument); the full suite; and whether tests/corekit's 5 tests are affected, which this diff does
not touch.

[JarryShaw]

GOOD TO GO carries to d47a6dcb9, and I can say that with more confidence than usual: the change is
provably prose-only. Tokenised both heads excluding comments and docstrings — 889 non-docstring tokens
before, 889 after, sequence identical. No code, assertion or import moved, so the verdict on f03f1d551
transfers rather than needing a fresh round. Labelled review: good-to-go. tests/vendor 118 passed / 0
failures at this head.

The correction landed, and the worker added a fact better than the one I gave it. I had said
assertWarnsRegex uses isinstance, so a genuine subclass would match — true, and it asked the obvious
next question: why does that not rescue this case? Because re-importing re-mints the base class too. My
own measurement:

g1 is g2: False
issubclass(g2,g1): False | issubclass(g1,g2): False
g1 base: BaseWarning 93949313565344
g2 base: BaseWarning 93949328592240   <- re-minted, not shared
first common ancestor: UserWarning    <- the builtin
same __module__/__name__: True

So the two generations are not related classes at all; their MROs first converge on the builtin
UserWarning. isinstance against a stale binding therefore rejects an instance of the fresh generation —
and because both carry the identical __module__ and __name__, the failure message names exactly the
class that was raised, which is why it reads as self-contradictory. The docstring now says all of that.
It also kept the original's "not by name" clause, correctly: a name-based match would have succeeded, so
that half was true and load-bearing.

One honest reservation. The setUp docstring is now 39 lines, up from 29, for a two-line fix. I am
keeping it, because every added fact is one I had to measure rather than read, and the file's own module
docstring runs to 165 lines so this is consistent with its house style rather than an outlier. But it is at
the limit, and if a later round wants it trimmed I would not defend the length — only the content.

No invented correction on the tuple point, which is right: the docstring never claimed a tuple was
required, so there was nothing to fix. It independently confirmed all ten purge_modules call sites under
tests/vendor/ spell it purge_modules(['pcapkit']).

One environmental note it flagged, worth recording because it will recur: this branch is checked out in
another agent's worktree, so it could not create the branch locally and pushed from a detached HEAD via
HEAD:refs/heads/…. That other worktree is now one commit behind the remote; it correctly did not touch it.

UNVERIFIED by it: that under discover this module is imported before any sibling purges, and that #981
pins the same skew in RegistrationGateTests — both left as written on my instruction, and both were
confirmed by the earlier round. No Sphinx render, no linters, no pytest (it masks this class).