Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistent serialization of BigInt GraphQL scalar #74

Closed
tuler opened this issue Sep 2, 2023 · 1 comment
Closed

Inconsistent serialization of BigInt GraphQL scalar #74

tuler opened this issue Sep 2, 2023 · 1 comment
Assignees
Labels
bug Something isn't working
Milestone

Comments

@tuler
Copy link
Member

tuler commented Sep 2, 2023

🙂 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:

"Request submitted to the application to advance its state"
type Input {
  ...
  "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.

if value <= i32::max_value() as i64 {

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

{
  inputs {
    edges {
      node {
        timestamp
        blockNumber
      }
    }
  }
}

🌎 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.

@tuler tuler added the bug Something isn't working label Sep 2, 2023
@gligneul gligneul added this to the 1.0.1 milestone Sep 2, 2023
@gligneul gligneul moved this to 📋 Backlog in Node Unit Sep 2, 2023
@gligneul gligneul moved this from 📋 Backlog to 🏗 In progress in Node Unit Sep 4, 2023
@gligneul gligneul self-assigned this Sep 4, 2023
@gligneul
Copy link
Contributor

gligneul commented Sep 5, 2023

Solved by cartesi/rollups#232

@gligneul gligneul closed this as completed Sep 5, 2023
@github-project-automation github-project-automation bot moved this from 🏗 In progress to ✅ Done in Node Unit Sep 5, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Archived in project
Development

No branches or pull requests

2 participants