Table Api Query on Int64 (long) column returning extra results

Which service(blob, file, queue, table) does this issue concern?

table

Which version of the Azurite was used?

3.29

Where do you get Azurite? (npm, DockerHub, NuGet, Visual Studio Code Extension)

npm and ran code from github main

What's the Node.js version?

9.8.1

What problem was encountered?

GET /devstoreaccount1/table()?$filter=PartitionKey%20ne%20%27Current%27%20and%20PlayIndex%20ge%2012L%20and%20PlayIndex%20lt%2013L HTTP/1.1

I do a query and find elements with playindex 12 (expected) but also 120-129 (wrong). This works perfectly fine against azure storage account so is specific to azurite. Also works fine if you drop the L from the query so it treats params as Int32.

Steps to reproduce the issue?

Add entities with a Int64 column and increment +1 each time to new column (add loads) then do a query for less than or equal to a small number and you'll get the extra results.

Have you found a mitigation/solution?

Workaround - dropping the L's off the query does the trick but fearful I may run into trouble on bigger numbers.

Solution attempt - I've had a dig around the code and it is because the filter value 13 is stored as a string as opposed to numeric so I ended up here:

QueryParser.ts

private visitNumber(): IQueryNode {
    const token = this.tokens.next(t => t.kind === "number") || this.throwUnexpectedToken("number");

    if (token.value!.endsWith("L")) {
      // This is a "long" number, which should be represented by its string equivalent
      return new ConstantNode(token.value!.substring(0, token.value!.length - 1));
    } else {
      return new ConstantNode(parseFloat(token.value!));
    }
  }

Adding a parseInt around the substring makes my case work correctly but the comment above suggests this is wrong, probably due to node numbers being smaller than int64. To try and fix I believe would entail a large code change that unfortunately I don't have the time for.

Azure / Azurite