You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The GraphQL schema language supports the scalar types of String, Int, Float, Boolean, and ID.
For other types it supports custom Scalars. BigInt is one of those.
The implementation of custom Scalars are typically left to the GraphQL implementation, which in general provide some sort of coercing implementation method.
In general BigInt types are serialized to strings. One of the reasons is that JSON does not support coercion of number literals to the native BigInt type.
Other blockchain indexers that provide a GraphQL interface coerce BigInt to string.
TheGraph supports BigInt and always serialize as string.
Subsquid also supports BigInt and always serialize as string.
We should follow our schema definition and also always serialize BigInt as string.
We currently use BigInt in two locations:
"Request submitted to the application to advance its state"typeInput {
...
"Timestamp associated with the input submission, as defined by the base layer's block in which it was recorded"timestamp: BigInt!"Number of the base layer block in which the input was recorded"blockNumber: BigInt!
...
}
🫠 Actual behavior
It looks like from my understanding that the server is serializing the value depending on the value itself.
If it's less than a i32 it is serializing as int. Otherwise it serializes as string.
We should not serialize conditionally on the value. Otherwise it can be very confusing for the parser, who will also need to conditionally parse without the proper context.
🙂 Expected behavior
The GraphQL schema language supports the scalar types of String, Int, Float, Boolean, and ID.
For other types it supports custom Scalars. BigInt is one of those.
The implementation of custom Scalars are typically left to the GraphQL implementation, which in general provide some sort of coercing implementation method.
In general BigInt types are serialized to strings. One of the reasons is that JSON does not support coercion of number literals to the native BigInt type.
Other blockchain indexers that provide a GraphQL interface coerce BigInt to string.
TheGraph supports BigInt and always serialize as string.
Subsquid also supports BigInt and always serialize as string.
We should follow our schema definition and also always serialize BigInt as string.
We currently use BigInt in two locations:
🫠 Actual behavior
It looks like from my understanding that the server is serializing the value depending on the value itself.
If it's less than a i32 it is serializing as int. Otherwise it serializes as string.
rollups-node/offchain/graphql-server/src/schema/scalar.rs
Line 123 in 1da90a4
We should not serialize conditionally on the value. Otherwise it can be very confusing for the parser, who will also need to conditionally parse without the proper context.
🧪 Minimal test case
Query the server at
https://0x9f12d4365806fc000d6555acb85c5371b464e506.sepolia.rollups.staging.cartesi.io/graphql
🌎 Environment
Rollups 1.0.0
✔️ Possible solutions
We should stick to the type definition.
If type definition is
BigInt
coerce as string.If type definition is
Int
coerce as number.The text was updated successfully, but these errors were encountered: