Incorrect handling of enum input value coercions

[gmac]

Describe the bug

Input coercion errors raised by leaf types are pretty spotty on validating correctly. I've included a complete test suite below, but the summary is:

• Enum types don't call coerce_input during validation. Therefore, the query is incorrectly valid, this input does not block execution, and the error manifests as a field execution error. Right error, wrong time.
• Scalars DO call coerce_input, and will statically invalidate the query to prevent it from executing. When this happens via variables, we get a good error message. When it happens via AST, not so much.

class GraphQLRubyTest < Minitest::Test
  class TestSchema < GraphQL::Schema
    class MyScalar < GraphQL::Schema::Scalar
      def self.coerce_input(value, ctx = nil)
        raise GraphQL::ExecutionError.new("boom")
      end
    end

    class MyEnum < GraphQL::Schema::Enum
      def self.coerce_input(value, ctx = nil)
        raise GraphQL::ExecutionError.new("boom")
      end

      value "BOOM"
    end

    class Query < GraphQL::Schema::Object
      field :scalar, String do |f|
        f.argument :input, MyScalar, required: true
      end

      field :enum, String do |f|
        f.argument :input, MyEnum, required: true
      end
    end

    query(Query)
  end

  def test_reports_validation_errors_with_scalar_ast
    query = ::GraphQL::Query.new(TestSchema, "{ scalar(input: 1) }")
    query.result.to_h

    # This is sort of the right error, but is missing a bunch of relevant information
    # {"errors" => [{"message" => "boom"}]}

    # This works...
    refute query.valid?
  end

  def test_reports_validation_errors_with_scalar_variables
    query = ::GraphQL::Query.new(TestSchema, "query($input: MyScalar!) { scalar(input: $input) }", variables: { input: 1 })
    query.result.to_h

    # This is the correct error
    # {"errors" => [{
    #   "message" => "Variable $input of type MyScalar! was provided invalid value",
    #   "locations" => [{"line" => 1, "column" => 7}],
    #   "extensions" => {"value" => 1, "problems" => [{"path" => [], "explanation" => "boom"}]},
    # }]}

    # This works...
    refute query.valid?
  end

  def test_reports_validation_errors_with_enums_ast
    query = ::GraphQL::Query.new(TestSchema, "{ enum(input: BOOM) }")
    query.result.to_h

    # This is a field execution error, it should have been a variable error that blocked execution
    # {"errors" => [{"message" => "boom", "locations" => [{"line" => 1, "column" => 3}], "path" => ["enum"]}], "data" => {"enum" => nil}}

    # This fails... query is valid?
    refute query.valid?
  end

  def test_reports_validation_errors_with_enum_variables
    query = ::GraphQL::Query.new(TestSchema, "query($input: MyEnum!) { enum(input: $input) }", variables: { input: "BOOM" })
    query.result.to_h

    # This is a field execution error, it should have been a variable error that blocked execution
    # {"errors" => [{"message" => "boom", "locations" => [{"line" => 1, "column" => 26}], "path" => ["enum"]}], "data" => {"enum" => nil}}

    # This fails... query is valid?
    refute query.valid?
  end
end

[rmosolgo]

I definitely see what you mean about these being inconsistent. Maybe the problem is that coerce_input is currently doing two different jobs. One one hand, it's implementing the spec's rules about handling scalars, for example:

When expected as an input type, any string (such as "4") or integer (such as 4 or -4) input value should be coerced to ID as appropriate for the ID formats a given GraphQL service expects. Any other input value, including float input values (such as 4.0), must raise a request error indicating an incorrect type.

https://spec.graphql.org/September2025/#sel-GAHXZHDCAACKesgR

graphql-ruby/lib/graphql/types/id.rb

Lines 12 to 20 in c4f07cd

	def self.coerce_input(value, _ctx)
	case value
	when ::String
	value
	when Integer
	value.to_s
	else
	nil
	end

On the other hand, it also does some dynamic value casting to make application logic easier (as with enums).

Here's where scalars implement validation by coercing:

graphql-ruby/lib/graphql/schema/scalar.rb

Lines 43 to 46 in c4f07cd

	def validate_non_null_input(value, ctx, max_errors: nil)
	coerced_result = begin
	coerce_input(value, ctx)
	rescue GraphQL::CoercionError => err

IIRC It was once raised as a bug, long ago, that coerce_input is actually called twice during execution, because that result is thrown away.

Enum, however, implements validate_non_null_input without coercing (I bet that results in the different behavior):

graphql-ruby/lib/graphql/schema/enum.rb

Lines 180 to 191 in c4f07cd

	def validate_non_null_input(value_name, ctx, max_errors: nil)
	allowed_values = ctx.types.enum_values(self)
	matching_value = allowed_values.find { |v| v.graphql_name == value_name }
	if matching_value.nil?
	GraphQL::Query::InputValidationResult.from_problem("Expected #{GraphQL::Language.serialize(value_name)} to be one of: #{allowed_values.map(&:graphql_name).join(', ')}")
	else
	nil
	end
	# rescue MissingValuesError
	# nil
	end

Maybe a way to standardize this is to implement def self.validate_non_null_input for the built-in scalars so that they don't call coerce_input. (I imagine the old base implementation would need to stick around for compat with custom scalars in the wild). It doesn't address all the issues above but it's ... something.

[gmac]

IIRC It was once raised as a bug, long ago, that coerce_input is actually called twice during execution, because that result is thrown away.

This signals an implementation oddity, IMO. I've been working with Claude to port the GraphQL-js reference implementation of input coercions. The spec system works as a single-pass traversal where errors are collected while building the coerced input for use. Variables are built once into valid state, then arguments are built again into valid state and directly collect pre-coerced variable values. Going by the spec, coercion would only happen once per input position. I have noticed that GraphQL Ruby does a lot of work in passes though, which I suspect it where that multi-coercion would happen. It's also pretty novel that GraphQL Ruby doesn't always treat inputs as static values, which would also lead to multiple coercions (and does lead to multiple validations of them)