You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
$ref-valued additionalProperties map values are not deep-validated or cast. When additionalProperties is a $ref to a component, the map values are admitted as a typed map but the referenced schema's rules are not applied to each value, and the values are not hydrated/cast into the referenced Data class. (Touches the same area as the no-op noted in Document validation no-ops: hostname/byte/binary/password formats, map-of-$ref values, scalar-union rules #18.)
Impact
Spec-invalid map values pass validation, and $ref map values are not cast to their Data type, so consumers get untyped/unvalidated payloads where the spec promised a structured, validated shape. Correctness gap.
What correct support looks like
each patternProperties entry contributes value rules keyed on the matching keys (mirroring the nested-object rules pipeline)
$ref-valued additionalProperties maps validate each value against the referenced schema's rules and hydrate values into the referenced Data class
Both gaps are recorded in openapi-laravel.unsupported.json (the drift-checked fidelity report): patternProperties value schemas and deep $ref map-value validation/casting are listed as correctness-affecting constructs not yet faithfully represented. Related closed issues: #65 (key false-rejection, fixed), #18 (map-of-$ref no-op).
Problem
Two related map-value gaps:
patternPropertiesvalues are never validated. Keys matching apatternPropertiesregex are admitted under closed-object enforcement (the false-rejection bug patternProperties combined with default additionalProperties:false enforcement false-rejects valid keys #65 is fixed), but the VALUE schema attached to each pattern is never translated into rules. A value of the wrong type/shape under a matching key passes.$ref-valuedadditionalPropertiesmap values are not deep-validated or cast. WhenadditionalPropertiesis a$refto a component, the map values are admitted as a typed map but the referenced schema's rules are not applied to each value, and the values are not hydrated/cast into the referenced Data class. (Touches the same area as the no-op noted in Document validation no-ops: hostname/byte/binary/password formats, map-of-$ref values, scalar-union rules #18.)Impact
Spec-invalid map values pass validation, and
$refmap values are not cast to their Data type, so consumers get untyped/unvalidated payloads where the spec promised a structured, validated shape. Correctness gap.What correct support looks like
patternPropertiesentry contributes value rules keyed on the matching keys (mirroring the nested-object rules pipeline)$ref-valuedadditionalPropertiesmaps validate each value against the referenced schema's rules and hydrate values into the referenced Data classadditionalProperties: falseenforcement stays correct (no regression of patternProperties combined with default additionalProperties:false enforcement false-rejects valid keys #65)Current behavior (recorded in fidelity report)
Both gaps are recorded in
openapi-laravel.unsupported.json(the drift-checked fidelity report):patternPropertiesvalue schemas and deep$refmap-value validation/casting are listed as correctness-affecting constructs not yet faithfully represented. Related closed issues: #65 (key false-rejection, fixed), #18 (map-of-$refno-op).