Repository navigation
SettingsFrame.settings passes a Schema class to ListField's item_type instead of a SchemaField #459
Description
Activity
Correction to this issue's text: the masking symptom is
KeyError: 'flags', notKeyError: 'length'.I wrote that the SETTINGS pack path "dies earlier with
KeyError: 'length'". That is wrong, and PR #462's reviewer caught it. Reproduced on0283a6d59:proto = object.__new__(HTTPv2) schema = proto.make(type=Frame.SETTINGS, sid=0, frame={'settings': [(Setting.HEADER_TABLE_SIZE, 4096)]}) bytes(schema)
File ".../pcapkit/protocols/schema/application/httpv2.py", line 144, in post_process if packet['flags'][name]: KeyError: 'flags'So the field that cannot be reached is
flags, notlength, and the raising site isFrameType.post_processathttpv2.py:144rather than a length callback.'length'was carried over from #445's CGA Parameters symptom, which genuinely isKeyError: 'length'on a different field in a different module — I reused the phrasing without re-checking what SETTINGS actually raises.The substance of this issue is unaffected, and worth restating so the correction is not read as a retraction:
SettingsFrame.settingsreally does pass theSettingPairclass toListField'sitem_typewhere a field instance belongs, with the type error silenced by# type: ignore[arg-type].ListField._item_typeholding aSchemaMetais still the defect.- It really is masked by A nested schema cannot reach the enclosing packet's fields by name, so CGA Parameters raises KeyError: 'length' #445 today — just by a
flagslookup rather than alengthone. Both are the same underlying fault, a nested schema unable to reach an enclosing field by name, so the masking claim holds. EXPECTED_FAILURES['httpv2-frame/SETTINGS']recordsGap('CONSTRUCT', "KeyError: 'flags'", …)— the harness had the right symptom all along, which is where I should have checked rather than reusing A nested schema cannot reach the enclosing packet's fields by name, so CGA Parameters raises KeyError: 'length' #445's wording.
Noting for whoever picks this up: the same wrong symptom propagated into PR #462's test docstring and description, and its reviewer has flagged it there too.
- added a commit that references this issue
on Sep 18, 2026
SettingsFrame.settingspasses aSchemaclass whereListFieldexpects a field instance, with the resulting type error silenced by a# type: ignore[arg-type].The site
pcapkit/protocols/schema/application/httpv2.py:283-285:Every other
ListFieldin the tree wraps its schema item in aSchemaField— for examplepcapkit/protocols/schema/transport/tcp.py:393isitem_type=SchemaField(length=8, schema=SACKBlock), andinternet/hip.py:260,internet/mh.py:535andtransport/sctp.py:702follow the same shape.Confirmed on
e2d8ed6d1So
_item_typeholds the metaclass-produced class object rather than a field, and thetype: ignoreis what let it through review — mypy had it right.Consequence
ListField.unpack's schema branch callsself._item_type(packet)to build a configured per-item field (see #433, which corrected a related bug on that line). Calling aSchemaclass with a packet dict does not produce a field; it attempts to construct a schema instance from a dict positionally. Depending on the branch taken, this either raises or silently mis-parses.Why this was unreachable until now
It sits behind the nested-packet fault in #445: the SETTINGS frame's pack path died earlier with
KeyError: 'length'. PR #457 fixes #445, and this becomes reachable — the agent implementing it reportedSETTINGSas one of five HTTP/2 frames that then fail on distinct, previously-unreachable defects.Fix
Wrap it as the siblings do:
and remove the
# type: ignore[arg-type], confirming with mypy rather than assuming — the baseline is 128 errors in 41 files. A regression test should exercise a real SETTINGS frame round trip rather than a fake, since a fake with a compatible__call__would hide the distinction.Provenance
Surfaced by the agent implementing #445 (PR #457) and verified independently before filing. Related: #433 (the same
ListFieldschema branch), and #445 which currently masks this.