RicoSuter / NSwag

The Swagger/OpenAPI toolchain for .NET, ASP.NET Core and TypeScript.
http://NSwag.org
MIT License
6.7k stars 1.24k forks source link

Unhandled OverflowException on decimal property with Range attribute #1365

Open older opened 6 years ago

older commented 6 years ago

System.ComponentModel.DataAnnotations.RangeAttribute doesn't have constructor for decimal type. One of alternatives is to use constructor which accepts double values for boundaries. JSON schema generator tries to create instance of type using value provided as maximum boundary and fails if double value is greater than decimal.MaxValue with the following exception:

System.OverflowException: Value was either too large or too small for a Decimal.
  in System.Decimal..ctor(Double value)

As far as I can tell it is common practice to use Range attribute with something like double.MaxValue if you only want to have lower limit on your value. Even (double)decimal.MaxValue would fail as the value produced after cast is actually greater than decimal.MaxValue.

The issue is easy to reproduce by creating Web API method with the following response class and trying to generate swagger spec in NSwagStudio:

using System.ComponentModel.DataAnnotations;
public class ResponseDto
{
    [Range(0.0, double.MaxValue)]
    public decimal AnyPositiveDecimal { get; set; }
}
RicoSuter commented 6 years ago

I think we can handle double.MaxValue as no upper limit, but because min/max is modeled as decimal we cannot support big values in ranges...

We need to fix this here: https://github.com/RSuter/NJsonSchema/blob/master/src/NJsonSchema/Generation/JsonSchemaGenerator.cs#L881

older commented 6 years ago

Would that be possible to treat OverflowException on any of the boundary values as no limit?

RicoSuter commented 6 years ago

Looking at the code this should be possible, we just don't set schema.Minimum or schema.Maximum when value is exactly == double.MaxValue, etc.

RicoSuter commented 6 years ago

Related: https://github.com/RSuter/NJsonSchema/issues/676

older commented 2 years ago

I cannot reproduce this with NSwag 13.15.1 anymore. Should I close the issue?