Fastapi: Large Integer Corruption With Swagger + Mozilla Firefox + FastAPI (Tested on repl.it and localhost). Still not sure if its Swagger, FastAPI or Mozilla Firefox That Is Causing The Issue

[cheesycod]

First check

• [X] I added a very descriptive title to this issue.
• [X] I used the GitHub search to find a similar issue and didn't find it.
• [X] I searched the FastAPI documentation, with the integrated search.
• [X] I already searched in Google "How to X in FastAPI" and didn't find any information.
• [x] I already read and followed all the tutorial in the docs and didn't find an answer.
• [UNSURE] I already checked if it is not related to FastAPI but to Pydantic.
• [UNSURE] I already checked if it is not related to FastAPI but to Swagger UI.
• [UNSURE] I already checked if it is not related to FastAPI but to ReDoc.
• [X] After submitting this, I commit to one of:
  
  
  
  • Read open issues with questions until I find 2 issues where I can help someone and add a comment to help there.
  
  
  • I already hit the "watch" button in this repository to receive notifications and I commit to help at least 2 people that ask questions in the future.
  
  
  • Implement a Pull Request for a confirmed bug.
  
  

Example

Here's a self-contained, minimal, reproducible, example with my use case:

from fastapi import FastAPI
from pydantic import BaseModel
app = FastAPI()
class TruncTest(BaseModel):
    integer: int
    string: str
@app.post("/trunctest")
async def trunc_test(a: TruncTest):
    print("Int: " + str(a.integer) + "Str: " + a.string)

Description

When I tried testing this with a POST request (using swagger, since thats the only way I know of to do a post request):

{
"integer": 563808552288780322,
"string": "563808552288780322"
}

I do not know whether this is an issue with FastAPI or Swagger or even Mozilla Firefox

Environment

• OS: [e.g. Linux / Windows / macOS]: Linux (fedora rawhide, kernel version: Linux localhost.localdomain 5.10.0-0.rc4.20201119gitc2e7554e1b85.81.fc34.x86_64 #1 SMP Thu Nov 19 20:45:31 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux)

• FastAPI Version [e.g. 0.3.0]: 0.61.2

To know the FastAPI version use:

python -c "import fastapi; print(fastapi.__version__)"

• Python version:

To know the Python version use: Python 3.9.0

python --version

Additional context

[Kludex]

Well, for those who didn't get it, the issue is with the integer field. It's not a FastAPI issue, it's a Swagger one.

Proof: run the below command on your terminal, and you'll see it's not truncated.

curl -X POST "http://127.0.0.1:8000/trunctest" -H "accept: application/json" -d "{\"integer\": 563808552288780322, \"string\": \"563808552288780322\"}"

[cheesycod]

thanks, that gives the appropriate results

[sm-Fifteen]

Notice that 563808552288780322 happens to be larger than the javascript constant for Number.MAX_SAFE_INTEGER (since integers in JS are stored as floats, they only get 53 bits of actual precision), so it would make sense that the number would lose precision at very high values.

You get the same kind of precision issue if you try this in Python.

>>> int("563808552288780322")
563808552288780322

>>> float("563808552288780322")
5.6380855228878035e+17

>>> int(float("563808552288780322"))
563808552288780352

For the record, RFC 7159 mentions how integers outside of the ±2^53 range, while not outright forbidden by the ECMA-404 JSON spec, might run into interoperability issues.

[cheesycod]

Unfortunately, discord uses such large numbers so I guess I will have to just use strings for large numbers then

[sm-Fifteen]

Unfortunately, discord uses such large numbers so I guess I will have to just use strings for large numbers then

If memory serves me right, Discord uses Twitter snowflakes for their IDs, which have that caveat documented and advise that consumers of APIs using them use the string representation to avoid that sort of issue.