Open ArieGato opened 6 days ago
At a glance without looking at the repro, there's a chance this is related to serializer behaviours and JavaScript/JSON precision of large values in browsers. I've seen similar issues raised against ASP.NET Core itself with the same wrong number that were related to that.
If you want to check yourself to rule that out that would be useful, otherwise I'll look into it at some point in the near future.
Hi @martincostello
I can concur that the schema is generated correctly in code:
The open api document however contains this:
"id": {
"maximum": 9223372036854776000,
"minimum": 0,
"type": "integer",
"format": "int64"
},
The value's type is a decimal
rather than a long
in the screenshot. This suggests to me it's a rounding issue in the serialisation, and that's handled in the Microsoft.OpenApi library, rather than by Swashbuckle itself.
The issue is getting harder to grasp for me. I dug a little deeper and checked the output that was written to the HttpResponse. The open api json that is returned is in fact correct. All the time I was debugging in Edge.
In Chrome the json is shown without some extra Microsoft magic.
However... The Swagger UI also doesn't render the correct maximum value. So I guess it ends here.
Any suggestions on how to go forwards?
I think as I mentioned in my first comment, you're hitting issues with Javascript's precision when it comes to dealing with very large numbers. I'm not aware of a way to deal with it.
Describe the bug
The maximum value of a property of type long is generated incorrectly. The issue occurs when the property is decorated with a custom range attribute derived from
RangeAttribute
. The generated value is 9223372036854776000, but should be 9223372036854775807.Expected behavior
The expected behavior is that the generated max value is the correct max value of a long data type: 9223372036854775807
Actual behavior
The generated value is 9223372036854776000
Steps to reproduce
Exception(s) (if any)
No response
Swashbuckle.AspNetCore version
7.0.0
.NET Version
any
Anything else?
The issue was previously reported here: 1038