$ref pointing at the same schema causes a resolver error
See original GitHub issueQ&A
- OS: macOS
- Browser: chrome
- Version: 79
- Method of installation: npm swagger-ui-react
- Swagger-UI version: 3.24.3
- Swagger/OpenAPI version: OpenAPI 3.0
Content & configuration
I have a $ref that is a causing a resolver error (#/components/schemas/PartsOrderLine/properties/listPrice/allOf/0
). The main difference I can see to other working refs is that it is pointing at the same schema, although it does not throw an error if I omit /allof/0
.
I have removed as much of the spec as possible, whilst retaining the error in order to simplify the problem.
For now I have ended up manually copying the information from the $ref instead of using a $ref, but that is not ideal.
Example Swagger/OpenAPI definition:
{
"openapi": "3.0.0",
"paths": {
"/parts-orders": {
"post": {
"responses": {
"201": {
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/PartsOrder"
}
}
}
}
}
}
},
"/parts-orders/{partsOrderId}": {
"get": {
"responses": {
"200": {
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/PartsOrder"
}
}
}
}
}
}
}
},
"components": {
"schemas": {
"PartsOrder": {
"type": "object",
"properties": {
"parts": {
"type": "array",
"items": {
"$ref": "#/components/schemas/PartsOrderLine"
}
}
}
},
"PartsOrderLine": {
"type": "object",
"properties": {
"listPrice": {
"allOf": [
{
"type": "string"
}
]
},
"orderPrice": {
"allOf": [
{
"$ref": "#/components/schemas/PartsOrderLine/properties/listPrice/allOf/0"
}
]
}
}
}
}
}
}
Swagger-UI configuration options:
import spec from '../../specs/parts-orders.json';
<SwaggerUI spec={spec} />
To reproduce…
Steps to reproduce the behavior:
- Load this up in Create React App
- See the resolver error
Expected behavior
The $ref resolves correctly.
Issue Analytics
- State:
- Created 4 years ago
- Comments:6 (3 by maintainers)
Top Results From Across the Web
Using $ref - Swagger
If the string value does not conform URI syntax rules, it causes an error during the resolving. Any members other than $ref in...
Read more >Swagger Resolver error, Could not resolve reference
I'm setting up a new asp.net core 3.1 project, exposing a RESTful API in FHIR format, which is a format extending JSON. I'd...
Read more >Understanding schema errors | HESA
Schema errors prevent the validation being run in full because the file cannot be read. This means that errors cannot be traced to...
Read more >GraphQL schema basics
Additionally, mutations are much more likely than queries to cause errors, because they modify data. A mutation might even result in a partial...
Read more >Troubleshoot deployment issues in Lambda
Concurrency: You might get an error if you try to create a function using reserved or provisioned concurrency, or if your per-function concurrency...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Thanks, that’s very helpful!
I have a call with the spec maintainers tomorrow so I’ll raise that as an issue.
Of course. The reason why
components
exist in the spec is to enable (and encourage) reusability. A reference like$ref: '#/components/schemas/PartsOrderLine/properties/listPrice/allOf/0'
suggests to me that the content of#/components/schemas/PartsOrderLine/properties/listPrice/allOf/0
should have been set it its own schema undercomponents
and referenced from both locations.Referencing objects directly under their
components
section makes sense, but digging in deeper with a ref is something I’d consider a… code smell.