Compiler accepts a Float literal that overflows (1e400) and writes inf into the artifact #5448

On main @ feb3b52, a Float literal outside the f64 range, such as 1e400, compiles without an error. The generated artifact then contains inf, which is neither valid JavaScript nor valid GraphQL.

Repro

schema.graphql:

type Query {
  f(x: Float): String
}

relay.config.json:

{
  "src": "./src",
  "schema": "./schema.graphql",
  "language": "javascript"
}

src/Q.js:

graphql`query PosQuery { f(x: 1e400) }`;

Running the compiler with no arguments in the directory that holds relay.config.json (the relay binary built from main @ feb3b52 with cargo build -p relay --bin relay) prints [INFO] Compilation completed., and src/__generated__/PosQuery.graphql.js contains:

        "value": inf
...
    "text": "query PosQuery {\n  f(x: inf)\n}\n"

• Importing the artifact in Node (v24.14.1) throws ReferenceError: inf is not defined.
• The operation text sends f(x: inf). graphql-js 16.11.0 parses inf as an enum value, and validating it against the schema fails with Float cannot represent non numeric value: inf.
• With -1e400 the artifact has -inf, and graphql-js cannot parse the text at all: Syntax Error: Invalid number, expected digit but got: "i".

The largest finite double, 1.7976931348623157e308, compiles and the artifact imports fine. macOS arm64 (Apple M-series).

Expected

A compile error for 1e400 and -1e400. The spec defines Float as "signed double-precision finite values", and an input value that is not representable by a finite IEEE 754 double (NaN, Infinity, or a value outside the available precision) must raise a request error (October 2021, section 3.5.2 Float).

To be precise about it: the grammar (section 2.9.2) does accept 1e400 as a FloatValue token, and graphql-js accepts it too: parse keeps it as a FloatValue and validate reports no errors. The finiteness rule is part of input coercion. But Relay cannot write the value into an artifact, and its parser already reports an integer literal that does not fit in an i64 as Invalid integer value (parser.rs#L2580-L2593). Reporting the existing Invalid floating point value error for a Float literal that overflows would be the matching behaviour.

Cause

The parser reads Float tokens with source.parse::<f64>() (parser.rs#L2594-L2611). For an out-of-range literal this returns Ok(inf) rather than an error, so the SyntaxError::InvalidFloat branch is never reached for it.

I have a fix that only accepts finite values there, with a parser fixture, and will open a PR.

This report was drafted with Claude Code (claude-opus-5-5); the outputs above are from the runs described.