Resolvers(?): numeric properties limited by double precision #3366
Description
Description
First mention in #3132. HeyAPI loses precision on properties such as maximum or minimum. The provided spec shows off an API that should be valid for some number but is actually never valid due to how js parses numbers. This could be much more subtle, for example multipleOf validating incorrectly. Both the exclusive max and the exclusive min were parsed as 6.805647338418771e+38, which leaves 0 overlap, while the original numbers had a range of 999,999,999 valid integers (and infinitely many reals). I don't think this is very important for normal usage of HeyApi, but would be nice to have the original string exposed in the resolvers API so people who need it can use it.
This is not necessarily a resolvers issue, but is most likely to come up when people (me) are using resolvers to handle arbitrary precision numbers. Maybe attaching a context to schemas which stores string representations of all properties could be useful? For example schema.context.exclusiveMinimum === '680564733841877078042476666692000000000'. This would require somewhat modern JS engines that support the context parameter.
Reproducible example or configuration
https://stackblitz.com/edit/ttamttam-hey-api-large-number-properties
OpenAPI specification (optional)
openapi: 3.0.4
info:
title: Sample API
description: Optional multiline or single-line description in [CommonMark](http://commonmark.org/help/) or HTML.
version: 0.1.9
paths:
/numbers:
get:
summary: Returns a list of users.
description: Optional extended description in CommonMark or HTML.
responses:
"200": # status code
description: A JSON array of user names
content:
application/json:
schema:
$ref: "#/components/schemas/numberWithPropertiesThatAreTooBig"
components:
schemas:
numberWithPropertiesThatAreTooBig:
type: number
exclusiveMinimum: 680564733841877078042476666692000000000
exclusiveMaximum: 680564733841877078042476666693000000000System information (optional)
No response