[Question] [Bug]: Inconsistent Relative Reference Resolution in Nested Schema Contexts
Nobody has claimed this yet.
Assessment
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Newbie friendliness
- 35/100
Research direction
Start with the reproduction context in OpenAPITools/openapi-generator#21492 and inspect how parentDirectory is handled while resolving relative $ref values through nested additionalProperties schemas. Verify the behavior against the OpenAPI 3.0 file-relative rule, including both path-file and schema-file references; done means nested references resolve consistently without build failures.
Written by the indexing model from the issue text.
Description
Question
There seems to be a bug when resolving nested schemas.
OpenAPI Generator incorrectly resolves relative $ref paths in schema files when they are referenced through nested contexts (like additionalProperties). The reference resolution context switches from file-relative to root-relative depending on the nesting level, causing build failures when using standard file-relative references.
This creates inconsistent behavior where:
References from path files work correctly using file-relative paths (../components/schemas/...)
References from schema files fail when using file-relative paths (NestedData.yaml)
This violates the OpenAPI 3.0 specification where all relative references should be resolved from the containing file's location.
Any ideas? parentDirectory seems to be resolved wrongly in this case?
Affected Version
Latest
Context
This issue first reported here: https://github.com/OpenAPITools/openapi-generator/issues/21492 (the project uses this library)
# Example OpenAPI or Swagger definition (optional)
Additional Details
Checklist
- I have searched the existing issues and documentation before asking.
- I have provided enough information for others to understand my question.
- Dominant language
- Java
- Stars
- 868
- Forks
- 560
- PR merge metrics
- No merged PRs in 30d
Getting set up
- No Dockerfile or Docker Compose file
- Has a pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from swagger-api/swagger-parser
-
InlineModelResolver.uniqueName throws StringIndexOutOfBoundsException for titles starting with a separator (camelCaseFlattenNaming)Possibly taken @arimu1 claimed this 37 days ago. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
swagger-api/swagger-parser#2386 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
swagger-api/swagger-parser#2168 ·
-
ResolveFully fails on internal references when the initial spec is read from a file URLPossibly taken A pull request linked to this issue is open or already merged. Open
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
swagger-api/swagger-parser#1922 · 2 comments · 1 reaction ·
-
[Bug]: `ResolverFully` does not process OAS 3.1 combinators and skips nested OAS 3.1 schema-valued keywordsPossibly taken A pull request linked to this issue is open or already merged. OpenBug
Difficulty 4/5 3-5 days Newbie friendliness 25/100
swagger-api/swagger-parser#2403 ·
-
[Bug]: Regression: resolveFully fails when components key does not match external file basenamePossibly taken @goutamadwant claimed this 31 days ago. OpenBug
Difficulty 4/5 3-5 days Newbie friendliness 58/100
swagger-api/swagger-parser#2399 · 3 comments ·
All issues in swagger-api/swagger-parser
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
area/docs
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
BoxChart rejects valid List.of data with NullPointerExceptionPossibly taken @PHJ2000 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 76/100