CoerceInputValue()

At a glance

• Identifier: #1179
• Stage: RFC1: Proposal
• Champion: @leebyron
• PR: CoerceInputValue()

Timeline

• 6 commits pushed on 2025-07-05:
  • Update spec/Section 3 -- Type System.md by @leebyron
  • Update spec/Section 3 -- Type System.md by @leebyron
  • Update spec/Section 6 -- Execution.md by @leebyron
  • Update spec/Section 6 -- Execution.md by @leebyron
  • Update spec/Section 6 -- Execution.md by @leebyron
  • Update spec/Section 6 -- Execution.md by @leebyron
• Spec PR created on 2025-07-04 by leebyron
• Commit pushed: CoerceInputValue() on 2025-07-04 by @leebyron

---

As an alternative to #1058 and #1178 - this is a more substantial overhaul of how input value coercion is defined in favor of a system of composed algorithms.

A quick summary of what this introduces:

• Introduces the concept of a coercion failure which has a similar "raised error" behavior, but is caught and translated into specific errors based on each callsite. That removes the awkwardness of "a request error is actually an execution error here".

• A new "Input Coercion" section which defines CoerceInputValue(). This is the point of reusability which handles nullability and then forks out to each specific input type.

• Algorithms for each kind of type's input coercion. Notably input objects and lists which have been under-defined (as an alt to #1058).

• A validation rule for default variable values, which I believe exists in graphql.js but was missing in spec.

Open Qs:

• Is this the right place for the Input Coercion subsection?

• Have I missed anything?