NoMethodError on dynamic_introspection when validate: false and field is missing at runtime

[XtofX]

Description

When executing a query with validate: false, if a field referenced in the query no longer exists in the runtime schema (due to schema changes, visibility profiles, or runtime masking), the interpreter crashes with:

NoMethodError: undefined method 'dynamic_introspection' for nil

This happens in GraphQL::Execution::Interpreter::Runtime#evaluate_selection where query.types.field(owner_type, field_name) returns nil, and the code proceeds to call field_defn.dynamic_introspection without a nil check.

Steps to reproduce

1. Create a schema with a field on a type
2. Execute a query referencing that field with validate: false
3. Remove the field from the schema (or change its visibility so it is no longer visible at runtime)
4. Execute the same query again with validate: false

schema.execute(
  "query { viewer { removedField } }",
  validate: false
)
# => NoMethodError: undefined method 'dynamic_introspection' for nil

Expected behavior

When validate: false is used and a field cannot be resolved at runtime, the interpreter should return a structured GraphQL::ExecutionError (e.g., "Field 'removedField' on type 'User' could not be resolved") rather than raising an unhandled NoMethodError. The field result should be set to null and execution should continue for the remaining fields.

Context

There are legitimate use cases for validate: false -- for example, when validation has already been performed externally, or when using persisted queries where the query was validated at registration time. In these scenarios, a field can go missing between the time validation was performed and execution time. The current behavior produces an unhelpful error with no indication of which field or type caused the problem, making debugging difficult.

A nil check on field_defn in evaluate_selection before accessing dynamic_introspection would make this error path graceful and informative.

[rmosolgo]

Hi! Thanks for the detailed report.

I think the bigger question is: What should GraphQL-Ruby when given an invalid query and validate: false?

Personally, I think crashing is acceptable behavior. I'm not convinced (yet?) that handling unvalidated, invalid queries is worth runtime overhead or maintainer overhead. (I suspect that this is the first of many, many things that go wrong when trying to run invalid queries without validation.)

Could you tell me more about your use case? Why not use validate: true here?

[XtofX]

Thanks for the quick response!

We use validate: true most of the time — the exception is persisted queries. For those, validation is performed once at registration time (which can be far in the past), so we use validate: false at execution time as a performance optimization.

Unfortunately, schemas evolve and breaking-change detection workflows aren't always 100% foolproof. We hit a production incident where a schema change caused pre-existing persisted queries to start failing. The NoMethodError crash made it difficult to identify which field was the problem — we had to dig through stack traces rather than seeing something like "Field 'removedField' on type 'User' could not be resolved".

To be clear: we're okay with the crash — if a query is invalid and unvalidated, crashing is reasonable behavior. We're only asking for a more specific error message when this situation occurs — something that names the field and type, rather than a bare NoMethodError on nil. The crash can stay; the lack of actionable context in the error is what hurt us.

[rmosolgo]

Thanks for sharing details about your scenario, that makes sense. Stack traces in execution are annoying because they don't yield any solid clues about what went wrong -- I agree improving the error message would be good here.

In developing the new execution module, I added some re-raising logic because I was debugging the core runtime code so much. Maybe something like that could be applied here, too, to cover a wide range of errors:

graphql-ruby/lib/graphql/execution/next/field_resolve_step.rb

Lines 229 to 233 in 984c43b

	rescue StandardError => err
	if @field_definition && !err.message.start_with?("Resolving ")
	# TODO remove this check ^^^^^^ when NullDataloader isn't recursive
	raise err, "Resolving #{@field_definition.path}: #{err.message}", err.backtrace
	else