fix: resolve dollar-ref chains and disambiguate component sections - #131
Open
MaxMichel2 wants to merge 1 commit into
Open
MaxMichel2 wants to merge 1 commit into
MaxMichel2 wants to merge 1 commit into
Conversation
MaxMichel2
added this pull request to stack #130
September 23, 2026 12:39
OpenApiParser.resolveRef previously keyed resolved components by a ref's trailing name segment only, ignoring which components.<section> it named, and followed a chain exactly one level deep. This fixes both: a ref's fragment must now declare the section its call site expects (parameters/responses/examples/headers), so a same-named entry in a different section can never be silently conflated with the one actually referenced; and ref chains are followed until a non-ref entry is reached, guarded by a visited-set of (document, fragment) pairs that fails clearly on a cycle instead of hanging.
MaxMichel2
force-pushed
the
fix/openapi-ref-resolution
branch
from
September 23, 2026 14:11
158fa62 to
4666236
Compare
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Stacked on #126 (PR chain: #123 → #124 → #127 → #128 → #129 → #126 → this) — merge in order.
OpenApiParser.resolveRefkeyed resolved$reftargets by a fragment's trailing name segment only, ignoring whichcomponents.<section>it actually named, and followed a$refchain exactly one level deep (a resolved entry's own$ref, if any, was not followed further). Real specs'componentssections cross-reference and chain more than this parser could handle — this is a prerequisite for #82/#84 (schema synthesis), which will need to resolve$refchains throughcomponents.schemasthe same way.What changed
OpenApiParser.resolveRef(private, insideParseContext): now takes an explicitsectionparameter ("parameters"/"responses"/"examples"/"headers") and validates a fragment's declared section against it — a$refnaming an unexpected section is rejected with a clear error instead of being silently resolved against whatever map the call site happened to expect, so a same-named entry in a different section can never be conflated with the one actually referenced.$ref(via a newrefOfparameter), until a non-ref entry is reached — a$refchain is now followed to completion instead of stopping after one hop.visited: MutableSet<Pair<OpenApiDocument, String>>tracks every(document, fragment)hop; revisiting one throws a clearIllegalStateExceptioninstead of looping forever.resolveParameter, and the response/example/header refs insideresolveResponseIndex/resolveHeaders) and the class-level KDoc's "Scope decisions" section to match.docs/modules/networkmock-core.md's "$refresolution" section updated — it documented the now-fixed "one level deep" limitation.Public API
None — the
openapipackage staysinternal(see #73's pure-seam requirement). Noapi.txtdiff.Tests
Added to
MockConfigRepositoryTest.kt, following the existing$reftest fixtures' style:`dollar-ref naming the wrong components section is rejected even if a same-named entry exists there`— a response$refpointing atcomponents/parameters/...instead ofcomponents/responses/..., with a same-named entry in both sections, now fails clearly instead of resolving against whichever map the call site expected.`local dollar-ref chain of two hops resolves to the final non-ref entry`—A→B→ literal content.`cyclic dollar-ref chain fails clearly instead of hanging`—A→B→A.Verification
All green, including a full repo-wide
testAndroidHostTestrun to confirm no fallout outside the networkmock modules.🤖 Generated with GitHub Copilot