Describe the bug
Two _missing_ range guards are duplicated, and the second copy of each is unreachable — so a minted member gets the wrong transport in its .proto.
Reproduction
Of 768 if guards in _missing_ (pcapkit/const/reg/apptype/apptype.py:2452-4765), exactly two conditions repeat:
6000 <= value <= 6063 at :2890 and again at :28936665 <= value <= 6669 at :3040 and again at :3043
The second copy is dead, so the first one's transport wins:
AppType.get(6010, proto='udp') -> <UDP.x11: 6010 [tcp]>
A member in the UDP registry claiming tcp-only.
Expected behavior
A member minted into the UDP registry for a UDP lookup should carry udp in .proto. Either the duplicate guards are merged with a combined transport, or the reachable one is chosen by the caller's transport rather than by source order.
System information
- OS Version: Linux 5.10 (Amazon Linux 2 int)
- Python Version: 3.14.7
- Python Implementation: CPython
pcapkit Version: checkout at 932cb48d1
Additional context
Found while verifying #736 after #754. This is #736's "related, same area" note, now half fixed: the second call no longer raises TypeError — the minted member is in the owner's registry, so is holds — but the wrong .proto survives.
apptype.py is generated, so the fix belongs in the crawler (pcapkit/vendor/reg/apptype/), not in the emitted file. Note this interacts with #732's deferred TransportProtocol retype: if only declared values are accepted, a merged guard needs a named combination rather than an OR.
Describe the bug
Two
_missing_range guards are duplicated, and the second copy of each is unreachable — so a minted member gets the wrong transport in its.proto.Reproduction
Of 768
ifguards in_missing_(pcapkit/const/reg/apptype/apptype.py:2452-4765), exactly two conditions repeat:6000 <= value <= 6063at:2890and again at:28936665 <= value <= 6669at:3040and again at:3043The second copy is dead, so the first one's transport wins:
A member in the UDP registry claiming tcp-only.
Expected behavior
A member minted into the UDP registry for a UDP lookup should carry
udpin.proto. Either the duplicate guards are merged with a combined transport, or the reachable one is chosen by the caller's transport rather than by source order.System information
pcapkitVersion: checkout at932cb48d1Additional context
Found while verifying #736 after #754. This is #736's "related, same area" note, now half fixed: the second call no longer raises
TypeError— the minted member is in the owner's registry, soisholds — but the wrong.protosurvives.apptype.pyis generated, so the fix belongs in the crawler (pcapkit/vendor/reg/apptype/), not in the emitted file. Note this interacts with #732's deferredTransportProtocolretype: if only declared values are accepted, a merged guard needs a named combination rather than an OR.