Data is null when a number value is higher than i32

[seekeramento]

Expected Behavior

We should be able to use "SimpleObject" with a struct that has a field of the type i64

Actual Behavior

When the value of a field of the type i64 exceeds the limit of i32, queries always return null. This is even when we do not include this field in our selected fields

Steps to Reproduce the Problem

1. Define a struct that uses the "#[derive(SimpleObject)]". This struct must have a field of the type i64.
2. Define a gql query that has a return type of the simple struct you defined. Make it return an instance of this struct, and make sure to set a high i64 value. Please note that this bug does not appear when the value is low.
3. Make GQL query that includes the i64 field.
4. The returning data value is always null.

Specifications

• Version:
  async-graphql = { version = "4.0.4", features = ["apollo_tracing"] }

• Platform:
  Windows 11

[sunli829]

The GraphQL spec doesn't support int64, I recommend using StringNumber instead.

https://spec.graphql.org/October2021/#sec-Int

The Int scalar type represents a signed 32-bit numeric non-fractional value. Response formats that support a 32-bit integer or a number type should use that type to represent this scalar.

[seekeramento]

I see. Does this mean that the field of my struct should be a "String"? Or there is another type to use as a part of this limitation?

[sunli829]

I recommend using string, StringNumber can help you.

#[derive(SimpleObject)]
struct Obj {
    int64_value: StringNumber<i64>,
}

[seekeramento]

Thanks, will try it.

[seekeramento]

How to import it?
use async_graphql::types::StringNumber;

or
use async_graphql::StringNumber;

Both did not work.

[seekeramento]

Got it. Needed to add string_number to the features
async-graphql = { version = "4.0.4", features = ["apollo_tracing", "string_number"] }

[seekeramento]

Cool StringNumber works fine, and it returns a string value. The only thing that I noticed that it does not implement the Default trait, which forces avoiding using the Default trait with the struct that uses it. Should we have a separate issue for this?

[sunli829]

Great idea, I've added it.

[seekeramento]

As explained in the chain, StringNumber is what we need to handle numbers larger than i32.