Number-based scalars are violating GraphQL Specification for NaN

[robross0606]

Issue workflow progress

Progress of the issue based on the
Contributor Workflow

• 1. The issue provides a reproduction available on GitHub, Stackblitz or CodeSandbox

  Make sure to fork this template and run yarn generate in the terminal.

  Please make sure the GraphQL Scalars package version under package.json matches yours.

• 2. A failing test has been provided
• 3. A local solution has been provided
• 4. A pull request is pending review

---

Describe the bug

If the value returned on a query resolver through a scalar like PositiveInt is NaN, the library is violating the GraphQL Specification by throwing an error:

Value is not a finite number: NaN

As per the specification:

2. If result is null (or another internal value similar to null such as undefined or NaN), return null.

To Reproduce Steps to reproduce the behavior:

Resolve a scalar value such as PositiveInt as NaN.

Expected behavior

Should return a null and not throw an error unless the value is required (i.e. PositiveInt!).

Environment:

• OS: Microsoft Windows [Version 10.0.19045.6396]
• GraphQL Scalars Version: 1.24.2
• NodeJS: 24.9.0

[ardatan]

I am not sure I follow. Could you share a reproduction in a PR or a sandbox environment like CodeSandbox?

[robross0606]

Creating a reproduction will take time I don't have at the moment, but I will try to get to it. In the meantime, let me try to explain again.

The Integer-based scalar resolvers in this library app appear to pass both input and output (query) variables through the _validateInt() function. However, this violates the GraphQL Specification which says that NaN, it should be coerced to null:

If result is null (or another internal value similar to null such as undefined or NaN), return null.

Instead, the scalars in this library validate it and throw an error due to passing it through the _validateInt() function. The same is true of float-based scalars which use _validateFloat(). I believe this problem would occur for NaN, Number.POSITIVE_INFINITY, Number.NEGATIVE_INFINITY, Number.INFINITY and possibly Number.EPSILON in varying degrees depending upon the actual scalar in question.

Does that make more sense?

[ardatan]

Still I am not sure I understand correctly what you mean. If you try to return NaN with Int from graphql-js, it will throw an error like; Int cannot represent non-integer value: NaN
We follow this behavior in our library.

  const schema = makeExecutableSchema({
    typeDefs: /* GraphQL */ `
    type Query {
      testInt: Int
    }
  `,
    resolvers: {
      Query: {
        testInt: () => NaN,
      },
    },
  });
  const query = parse(/* GraphQL */ `query {
    testInt
  }`);
  const result = executeSync({
    schema,
    document: query,
  });
  expect(result).toEqual({ data: { testInt: null }, errors: [expect.objectContaining({ message: 'Int cannot represent non-integer value: NaN' })] });

That's why I needed a reproduction in order to help you better for the issue you created here.

[robross0606]

If you try to return NaN with Int from graphql-js, it will throw an error..

Then both libraries are in violation of the specification. I've provided a link to the GraphQL Specification where it is clearly spelled out that NaN should be coerced to null on output. You're confusion is caused by another library also doing the wrong thing. You've correctly stated the problem space above so there is no further explanation or reproduction needed from my end. What you showed above should also not happen. The NaN should be coerced to null and returned without error.

[robross0606]

I am a bit confused by graphql-js behavior here as well since you can see several tickets and PRs in their history where they address NaN. For example: graphql/graphql-js@f485d55

Here you can specifically see that they are treating some of the cases differently. I have not yet traced thru all the historical changes they made.

[robross0606]

I have logged a similar ticket on the graphql-js project using your example. We'll see what they say.

[ardatan]

We take graphql-js as a reference implementation. If GraphQL-js decides to change it, we can change it too. But for now, we want to be aligned with the existing scalar implementation in there (Int, Float etc)