[email protected]

Features

• Allow coercing Int variables to Float - tninesling, pull/1011

  The GraphQL spec allows coercing Int values to Float in input positions (see
  input coercion). There are a couple things to note about this.

  • Strings are not allowed to be coerced in this position, even if they are
    numeric.
  • Ints can only be converted to Float when they are "representable by finite
    IEEE 754" floating point numbers.

  Since an IEEE 754 floating point double (f64) has 53 bits of precision, it can
  safely represent up to the value 2^53 - 1 as a finite value. Beyond that, the
  round trip from integer to float and back will lose information. This is
  represented with a new MAX_SAFE_INT constant which is often included in
  other languages like JavaScript's Number.MAX_SAFE_INT. When, we encounter an
  Int variable in a Float position, we ensure that its value is finitely
  representable.

  There is some nuance in that the spec does not say all floats have to be
  within this range. So, this implementation allows explicitly passed floats
  which are greater than that bound, only applying the integer conversion limit
  when coercing a value.

Fixes

• Validate missing fragments when parsing standalone executable documents - Abdel-Monaam-Aouini, pull/1003

  When validating standalone executable documents, the use of undefined fragment
  definitions will return a validation error. Previously, executable documents
  like the following would pass validation without errors, despite
  CompanyFragment being undefined.

  query {
    company {
      user {
        ...UserFragment
      }
      ...CompanyFragment
    }
  }
  fragment UserFragment on User {
    id
    name
  }

Maintenance

• Add benchmark for parsing and validation when a type has many extensions tninesling, pull/1000

  Introduces a new benchmark for query parsing and validation when a type has
  many extensions. We made an update in [email protected] to expose
  .iter_origins() for AST nodes, and we reimplemented .extensions() in
  terms of .iter_origins(). We were concerned that this may have caused a
  performance regression in parsing, but running this new benchmark against
  main with 1.28.0 as the base indicates no change in performance.