Skip to content

openapi3: preserve origin for a $ref to a schema under an arbitrary top-level key#21

Open
reuvenharrison wants to merge 4 commits into
masterfrom
origin-arbitrary-key-ref
Open

openapi3: preserve origin for a $ref to a schema under an arbitrary top-level key#21
reuvenharrison wants to merge 4 commits into
masterfrom
origin-arbitrary-key-ref

Conversation

@reuvenharrison

@reuvenharrison reuvenharrison commented Jul 12, 2026

Copy link
Copy Markdown

A $ref to a schema stored under an arbitrary top-level key in another file (e.g. ./schemas.yaml#/User, the Swagger-2-era "definitions bag") resolves through T.Extensions, a generic map that carries no origin, and the json round-trip that decodes it into the typed component drops origin entirely. With IncludeOrigin enabled the resolved schema then has a nil Origin, unlike the /components/schemas path.

Fix: on that generic-map path (and only there), re-derive the component file's origin tree, walk to the ref fragment, and apply the subtree — so the resolved object carries the same origins a typed resolution would, with the original file's line numbers. Best-effort: any failure leaves the object without origins, exactly as before. The common typed path is untouched.

Why it matters

A consumer that uses origins for source locations (error anchors, editor links, source slicing) gets the wrong location for any element behind this ref shape: the origin chain falls back to the referencing document, pointing at the $ref site in the root file instead of the schema's own file and line. Whole-file refs (./user.yaml) and components-structured refs already carry correct origins; this closes the remaining shape.

Repro test + fixtures included (TestOrigin_ExternalRefToArbitraryTopLevelKey); full openapi3 suite green.

fenollp and others added 4 commits July 11, 2026 15:30
Signed-off-by: Pierre Fenoll <pierrefenoll@gmail.com>
Signed-off-by: Pierre Fenoll <pierrefenoll@gmail.com>
… (C-02)

sliceMapToSlice built a []any sized to the largest attacker-supplied
array index before schema validation (maxItems) ever ran, letting a
~24-byte deepObject query parameter (e.g. param[items][50000000]=x)
force multi-gigabyte heap allocation. Cap the gap between supplied
elements and the reconstructed slice size, and reject negative
indexes.

Signed-off-by: Matías Insaurralde <matias@insaurral.de>
…op-level key

A $ref to a schema stored under an arbitrary top-level key in another file
(e.g. "./schemas.yaml#/User", the Swagger-2-era definitions bag) resolves
through T.Extensions, a generic map that carries no origin, and the json
round-trip that decodes it into the typed component drops origin entirely. With
IncludeOrigin enabled the resolved schema then has a nil Origin, unlike the
/components/schemas path.

Re-attach origins on that path: re-derive the component file's origin tree, walk
to the ref fragment, and apply the subtree, so the resolved object carries the
same origins a typed resolution would, with the original file's line numbers.
Best-effort; any failure leaves the object without origins, as before.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BqJA1X6suZYtR3tRbX8sLj
@reuvenharrison reuvenharrison marked this pull request as draft July 12, 2026 20:57
@reuvenharrison reuvenharrison marked this pull request as ready for review July 12, 2026 21:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants