RouteCollectionReader.GetString converts large numeric strings to scientific notation

[michaelglass]

Description

RouteCollectionReader.GetString converts string values containing large numbers to scientific notation, causing precision loss for int64 values.

Minimal Reproduction

open Microsoft.AspNetCore.Http
open Falco

[<EntryPoint>]
let main _ =
    let ctx = DefaultHttpContext()
    ctx.Request.RouteValues.Add("id", "9223372036854775807")  // Int64.MaxValue as string

    // The raw value is correct
    let rawValue = ctx.Request.RouteValues.["id"]
    printfn "Raw type: %s" (rawValue.GetType().Name)  // "String"
    printfn "Raw value: %s" (rawValue.ToString())      // "9223372036854775807"

    // But GetString converts it
    let route = Request.getRoute ctx
    let strValue = route.GetString "id"
    printfn "GetString: %s" strValue                   // "9.223372036854776E+18" (wrong!)

    0

Expected Behavior

GetString "id" should return "9223372036854775807" - the same string that was stored in RouteValues.

Actual Behavior

GetString "id" returns "9.223372036854776E+18" - the value has been converted through a floating-point type, losing precision.

Impact

This breaks int64 route parameter parsing for values larger than ~15 significant digits.

Environment

• Falco 5.2.0
• .NET 10.0

Workaround

Read directly from ctx.Request.RouteValues instead of using GetString:

match ctx.Request.RouteValues.TryGetValue(fieldName) with
| true, value when not (isNull value) -> value.ToString()
| _ -> ""

[michaelglass]

Additional Finding

TryGetInt64 also fails - it throws an OverflowException:

System.OverflowException : Arithmetic operation resulted in an overflow.
   at Falco.RequestDataExtensions.RequestValue.asInt64(RequestValue requestValue)
      in /home/pim/Source/git_falcoframework/Falco/src/Falco/RequestData.fs:line 72

Test code:

let ctx = DefaultHttpContext()
ctx.Request.RouteValues.Add("id", "9223372036854775807")

let route = Request.getRoute ctx
let result = route.TryGetInt64 "id"  // Throws OverflowException

This suggests asInt64 is parsing through a float or decimal internally, causing the overflow.

[pimbrouwers]

Thanks for all this effort Michael. It's my favourite part of working on this family of projects, and even more so, in this language.

I touched on this in the PR, but I am disappointed in the lack of testing, and inherently the code quality that emerges from it. I'm going to spend a few days enhancing the tests, fixing found bugs and deploying new a package version.

I appreciate this find and the completeness of your reporting!

[michaelglass]

thank you for Falco! Also happy about adding tests, or making a more surgical change (e.g. only affecting GetString)

[michaelglass]

should we call this closed?

[pimbrouwers]

thank you for Falco! Also happy about adding tests, or making a more surgical change (e.g. only affecting GetString)

I owe so much to this project and to everyone it's put me in touch with. So thank you as well!

I'll keep this open as a prod to myself to get this testing and new package out. Sound good?

[michaelglass]

FYI: I found this bug while playing with this library. I really like how it turned out so far:

https://github.com/michaelglass/Falco.UnionRoutes

[pimbrouwers]

FYI: I found this bug while playing with this library. I really like how it turned out so far:

https://github.com/michaelglass/Falco.UnionRoutes

This is so impressive. Really great docs as well. Would you be okay with me listing it on the main Falco readme under "Related Libraries"? I think a project like this needs to be highlighted. If so, PR the readme so you get both attributions.

As for our issue, once I sat down and started digging, before I knew it a new major version emerged (and an entirely new fleet of unit tests).

I've pushed it to nuget (6.0.0-alpha1) would love your thoughts. I've updated the changelog already, but haven't quite gotten to the migration doc yet.

Let me know what you think!