Summary
checkEncodingKeys (pass/validate.go) resolves Content.Encoding keys against the model each content is typed by. To reach every content it names the Payload-bearing fields by hand — Operation.Request, Response.Payload and Message.Payload — and its doc comment says so:
The fields that carry a Payload are named here — Operation.Request, Response.Payload and Message.Payload — so a new one has to be added by hand.
The test side states the same obligation in encodingCarriers() (pass/validate_encoding_test.go): "so one added to the IR has to appear here as well as there". Both lists are hand-written and nothing enforces either. A fourth field carrying an ir.Payload would be walked by neither, and no test would fail: its encoding keys would go unresolved, and an emitter rendering multipart parts from them would silently render no part for a key that misses.
Why this one is unusual
Every other hand-maintained list in the verification layer is held by a reflection-driven drift guard:
ir/irverify/indices.go names struct fields by string (FieldByName("Servers")) and is held by indexCarrierFields / integerFields, with TestIntegerFields_AreAllClassified walking the IR by reflection and failing on any unclassified integer field.walkChecks() is held by walkchecks_test.go.ir/nofloat_test.go derives the TypeKind set from the production sources rather than listing it.
grep -n reflect pass/*_test.go finds no completeness assertion over Payload-bearing fields — only the prose obligation. This is the one member of the family with a stated obligation and no guard.
Expected
A reflection-driven test in pass that enumerates the fields whose type is (or contains) ir.Payload reachable from ir.Document, and fails when one is absent from the carrier list checkEncodingKeys walks — the shape indices_test.go already uses for integer-index carriers.
Found while adding checks in pass/validate.go; filed rather than folded into that change.
Summary
checkEncodingKeys(pass/validate.go) resolvesContent.Encodingkeys against the model each content is typed by. To reach every content it names thePayload-bearing fields by hand —Operation.Request,Response.PayloadandMessage.Payload— and its doc comment says so:The test side states the same obligation in
encodingCarriers()(pass/validate_encoding_test.go): "so one added to the IR has to appear here as well as there". Both lists are hand-written and nothing enforces either. A fourth field carrying anir.Payloadwould be walked by neither, and no test would fail: its encoding keys would go unresolved, and an emitter rendering multipart parts from them would silently render no part for a key that misses.Why this one is unusual
Every other hand-maintained list in the verification layer is held by a reflection-driven drift guard:
ir/irverify/indices.gonames struct fields by string (FieldByName("Servers")) and is held byindexCarrierFields/integerFields, withTestIntegerFields_AreAllClassifiedwalking the IR by reflection and failing on any unclassified integer field.walkChecks()is held bywalkchecks_test.go.ir/nofloat_test.goderives theTypeKindset from the production sources rather than listing it.grep -n reflect pass/*_test.gofinds no completeness assertion overPayload-bearing fields — only the prose obligation. This is the one member of the family with a stated obligation and no guard.Expected
A reflection-driven test in
passthat enumerates the fields whose type is (or contains)ir.Payloadreachable fromir.Document, and fails when one is absent from the carrier listcheckEncodingKeyswalks — the shapeindices_test.goalready uses for integer-index carriers.Found while adding checks in
pass/validate.go; filed rather than folded into that change.