Console data edit/insert issue when dealing with big numbers

[gnekich]

Version Information

Server Version: <= 2.17.0
CLI Version (for CLI related issue): 2.17.0

Environment

Cloud / OSS / EE

What is the current behaviour?

If you have the numeric value saved in postgres table like numeric(78,0) most likely in cases where you want to capture uint256 value, ERC20 token value etc, etc... and turn on the flag HASURA_GRAPHQL_STRINGIFY_NUMERIC_TYPES="true" Hasura console will not be aware of this and when you open tab "edit" > change the value it will lose precision because parseFloat is being used on the string value from input.

What is the expected behaviour?

Stringify certain Postgres numeric types, specifically bigint ,numeric ,decimal and double precision as they don't fit into the IEEE-754 spec for JSON encoding-decoding.

Because HASURA_GRAPHQL_STRINGIFY_NUMERIC_TYPES is set to true, the value should be sent as string to the GraphQL, if I do this manually by updating request, it works. So the server is working as expected, issue is in the UI.

How to reproduce the issue?

1. Create postgres table with type numeric(78,0)
2. Open the Hasura Console
3. Go to Data > select table containing numeric column > Edit a specific row
4. Change numeric column to something big
5. Save

Any possible solutions/workarounds you're aware of?

There are two solutions I see, either we introduce a way to explicitly send different type to the API, ignoring the type of the column, example if the number is wrapped in quotes ("" or '') the component will not use parseInt or parseFloat but leave it as is. (It also seems that similar transformation is already being done with booleans "true": string -> true: boolean, which I could also fix in the PR because "True", "tRuE" or "1" would not be sent as true :) ...).

The second solution would be checking the state of the server finding the state of HASURA_GRAPHQL_STRINGIFY_NUMERIC_TYPES flag maybe through "/v1alpha1/config" and then send strings if it is active.

I'm looking for feedback on possible solutions, and I'm fine with creating PR for the first solution.

Keywords

IEEE-754, bigint, BigNumber, HASURA_GRAPHQL_STRINGIFY_NUMERIC_TYPES, --stringify-numeric-types

[gnekich]

I've created a possible fix;
https://github.com/gnekich/graphql-engine/tree/fix/big-number-issue
If someone from the team can review it and see if it make sense, the far better solution would be to somehow get state of HASURA_GRAPHQL_STRINGIFY_NUMERIC_TYPES flag from the server, and only then send the values as string, another way could be to check if the number is outside of the range of IEEE-754 and then send it as string.

Interesting finding while testing the fix is that it is also possible to send numeric value as string even if the HASURA_GRAPHQL_STRINGIFY_NUMERIC_TYPES is set to false, and it seems in postgres it will also be saved correctly, but UI will not show it correctly because the output in the response will not be the string. (If that is the case should we always send it as string? It would remove the problem completely)