swagger-api / swagger-api/swagger-parser
Unquoted integer `example:` value fails to parse when the spec includes a deeply nested schema elsewhere in spec
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 867
- Forks
- 560
- Avg merge
- 2d 21h
- Merged PRs (30d)
- 7
Description
Version: 2.1.29
Description:
We are seeing issue parsing a valid OpenAPI 3.0 spec with an unquoted example: when the spec includes a deeply nested schema elsewhere.
Steps to Reproduce:
When we try and parse this spec we don't see the error directly:
openapi: 3.0.1
info:
title: "Infinity reproduction"
version: 1.0.0
servers:
- url: http://example.com
paths:
/some-endpoint:
get:
responses:
"200":
description: Get something from endpoint
content:
application/json:
schema:
type: string
example: 68534049e7548
Internally this seems to be converted into json in the following way:
{
"openapi" : "3.0.1",
"info" : {
"title" : "Infinity reproduction",
"version" : "1.0.0"
},
"servers" : [ {
"url" : "http://example.com"
} ],
"paths" : {
"/some-endpoint" : {
"get" : {
"responses" : {
"200" : {
"description" : "Get something from endpoint",
"content" : {
"application/json" : {
"schema" : {
"type" : "string",
"example" : "Infinity"
}
}
}
}
}
}
}
}
}
See the value 68534049e7548 has been converted into Infinity. In our system this is not an issue for parsing although not ideal given it doesn't represent the example in the original yaml specification.
However, if I try to parse this document with a deply nested respose in s different path:
openapi: 3.0.1
info:
title: "Number format bug reproduction"
version: 1.0.0
servers:
- url: http://example.com
# this should fail and throw a number format exception in OpenAPIDeserializer.java caught on line 315
paths:
/foo:
get:
responses:
"200":
description: Get something
content:
application/json:
schema:
type: string
example: 68534049e7548
/bar:
get:
responses:
"200":
description: Get something else
content:
application/json:
schema:
type: object
properties:
flows:
type: array
items:
type: object
properties:
frames:
type: array
items:
type: object
properties:
root:
type: object
properties:
children:
type: array
items:
type: object
properties:
children:
type: array
items:
type: object
properties:
children:
type: array
items:
type: object
properties:
children:
type: array
items:
type: object
properties:
children:
type: array
items:
type: object
properties:
children:
type: array
items:
type: object
properties:
children:
type: array
items:
type: object
properties:
children:
type: array
items:
type: object
properties:
children:
type: array
items:
type: object
properties:
children:
type: array
items:
type: object
properties:
children:
type: array
items:
type: object
properties:
id:
type: string
What seems to be happening is the the 68534049e7548 value has been converted into Infinity and then it tries to parse it as a BigDecimal which failes with a java.lang.NumberFormatException: Character I is neither a decimal digit number, decimal point, nor "e" notation exponential mark.
The simple workaround is to quote the 68534049e7548 value and then it is treated as a string. The problem with that is the quotes are often removed when the spec is output and saved after parsing. We then have the same probem when the spec is parsed the next them round.
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.
Research direction
Start with OpenAPIDeserializer.java, especially the parsing path around the line 315 catch mentioned in the report. Reproduce the minimal and deeply nested OpenAPI documents, comparing how the unquoted example value is converted. Done means the valid value is preserved without converting to Infinity or raising a BigDecimal NumberFormatException.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java, openapi
- Domain
- api
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100