[BUG] Parsing fails for OpenAPI schema referenced multiple times
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
- Issue type
- Bug
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- javascript, typescript
- Domain
- api
Research direction
Start by running the parser against packages/openapi-schema-parser/test/documents/valid-asyncapi3.yaml, as described in the reproduction steps. Inspect the OpenAPI schema parser dependency and its existing tests to confirm the repeated-reference failure. Done means the document parses without InvalidTypeError and all OpenAPI 3.0 schemas load correctly.
Written by the indexing model from the issue text.
Description
Describe the bug.
An InvalidTypeError is thrown during document parsing of a valid OpenAPI 3.0 schema which uses nullable: true, even though schemaFormat was set correctly.
The error only occurs in some circumstances when a schema is referenced multiple times.
I previously reported this as https://github.com/asyncapi/openapi-schema-parser/issues/275 before the move of the openapi-schema-parser component.
The transformation of OpenAPI Schema to JSON Schema using the @openapi-contrib/openapi-schema-to-json-schema library, modifies the input OpenAPI Schema. This triggers the error when the same schema is transformed for a second time. This seems to be a bug in this version of the library; it occurs even though the cloneSchema parameter is set to true.
For the first reference, the schema with nullable gets correctly transformed from OpenAPI Schema:
type: ["string"] , nullable: true
to Json Schema:
type: ["string", "null"]
When it is then parsed again (because the same schema is also referenced from another location), the transformation fails with the InvalidTypeError because it doesn't expect a type with an array as value in an OpenAPI 3.0 Schema.
If this issue is accepted, I can create a pull request to update the @openapi-contrib/openapi-schema-to-json-schema dependency, which I verified fixes the issue (code is in this branch. I first tried a structuredClone on the input schema, but that didn't fix all occurrences of the issue.
Expected behavior
AsyncAPI being parsed without error, with all OpenAPI 3.0 schemas correctly loaded.
Screenshots
How to Reproduce
- Load this asyncapi document in AsyncAPI studio, or run the parser directly on it
- This will result in an
InvalidTypeError
🖥️ Device Information [optional]
- Operating System (OS): Windows 11
- Browser: Edge
- Browser Version: 153
👀 Have you checked for similar open issues?
- I checked and didn't find similar issue
🏢 Have you read the Contributing Guidelines?
- I have read the Contributing Guidelines
Are you willing to work on this issue ?
Yes I am willing to submit a PR!
- Dominant language
- TypeScript
- Stars
- 144
- Forks
- 146
- Avg merge
- 6m
- Merged PRs (30d)
- 9
Contributor 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 asyncapi/parser-js
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
-
microgrant
-
Difficulty 5/5 Over a week Newbie friendliness 38/100
-
Difficulty 4/5 3-5 days Newbie friendliness 58/100
All issues in asyncapi/parser-js
Similar issues
-
calcite-components needs triage refactor
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Esri/calcite-design-system#15203 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 91/100
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficulty 1/5 Under an hour Newbie friendliness 95/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Automattic/studio#4908 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 90/100