Repository navigation
reg: minted AppType members carry TransportProtocol.undefined, not their registry's transport #816
Description
Activity
Checkable blocker: #815 merged.
gh pr view 815 -R JarryShaw/PyPCAPKit --json state,mergedAt#815 rewrites the file this issue cites —
const/reg/apptype/apptype.py— and its four sibling registries, so every line number above goes stale on merge and any edit here would collide. #815 isreview: good-to-gowith one open question on transport-name support, so the hold should be short.Settle it together with that question if you can.
:2427's annotation is still'TransportProtocol | str'while #815 removes the string form fromregister_apptype; whichever way that lands, this site should match rather than diverge.- added and removed
on Sep 25, 2026 Checkable blocker: #775 resolved.
gh issue view 775 -R JarryShaw/PyPCAPKit --json stateUnblocked from #815 by its merge (
3118ed796), but this issue is downstream of #775, not independent of it. #816 is that mintedAppTypemembers carryTransportProtocol.undefinedinstead of their registry's transport — and #775 is that unrecognised values should not be minted into permanent members at all, per the maintainer's ruling quoted there: "so that we dont create registered enums out of unrecognised/unregistered values, unless user/caller explicitly created them."If #775 lands as ruled, there is no minted member left to carry the wrong
proto, and this issue dissolves rather than being fixed. Fixing it first would build a correctprotoonto members that are about to stop existing.So: sequenced behind #775, and likely to close with it rather than needing its own change. Re-examine when #775 resolves rather than assuming it is still live.
Re-examined now that #775 has resolved, and it dissolved exactly as predicted above. Measured on
mainat6102bf43fin a clean scratch worktree, with the tree under test asserted and printed:TREE /tmp/m816/pcapkit/__init__.py AppType.get(9999, proto=tcp ) -> TCP.distinct proto=<TransportProtocol.tcp: 1> registered=True AppType.get(9999, proto=udp ) -> UDP.distinct proto=<TransportProtocol.udp: 2> registered=True AppType.get(65000, proto=sctp) -> SCTP.unknown proto=<TransportProtocol.sctp: 3> registered=FalseThe third row is the case this issue was about — a value with no IANA assignment. It now comes back unregistered (
registered=False, absent from__members__) and itsprotois its own registry's transport, notTransportProtocol.undefined. The first two are real declared members, shown for contrast.So there is no minted member left carrying the wrong transport: #874 gave
AppTypean_unregistered_memberoverride that reconstructssvc/port/protofrom the branch it came from, and #878 finished the conversion so nothing inpcapkit/const/mints on a lookup miss except the documentedCGATypecarve-out. The defect had no separate fix; it stopped existing when the member stopped being created.Closing,
blockedremoved. Worth recording why this was sequenced rather than fixed: building a correctprotoonto members that were about to stop existing would have been work thrown away — the blocker comment above called that in advance, and it held.
Describe the bug
AppType._missing_mints span members carryingTransportProtocol.undefinedrather than the registry's own transport, so #806's guarantee — every member'sprotonames the registry it lives in — holds for declared members only.Expected behavior
A member minted into
TCPcarriesproto == TransportProtocol.tcp, the same as a declared one — somember.proto is cls.__transport__holds for every member without qualification.Additional context
Pre-existing, not introduced by #815, and #815 deliberately left it alone as out of scope. Found by #815's own author while proving the retyping, and recorded here so the qualification is tracked rather than implied: #815's new
test_every_member_renders_its_own_registrys_transport_protocolcovers the 12,391 declared members and says nothing about minted ones.Note
:2427's annotation is still'TransportProtocol | str', which is the string-name form #815 removed fromregister_apptype— so if names are being rejected across the API, this is a second site to settle, and if they are being kept, this one already supports them. That makes this issue adjacent to the open question on #815 rather than fully independent.Two traps for whoever takes it:
undefined.origin/main. feat(reg)!: retype AppType.proto to its own transport, and give register_apptype varargs (#806) #815 rewrites this file wholesale (+16/−14inapptype.py,+5293/−5292intcp.py), so citations here go stale the moment it merges.Related: #806, #815, #809, #575, #764.