GeezerVison

Problem

InstrumentationFieldFetchParameters.getField() (inherited from InstrumentationFieldParameters) goes through the ExecutionStepInfo supplier, which is () -> environment.get().getExecutionStepInfo(). So asking for the field definition in beginFieldFetching materialises the full lazily built DataFetchingEnvironmentImpl plus its ExecutionStepInfo on every fetch. For trivial PropertyDataFetcher fetches (a LightDataFetcher that never builds the environment itself) the instrumentation becomes the only reason the environment is built at all. ExecutionStrategy.fetchField already has the GraphQLFieldDefinition resolved eagerly before the environment supplier is created, so this cost is avoidable.

Motivating case: apollographql/federation-jvm#469 (see the "Possible follow-up in graphql-java" discussion) and apollographql/federation-jvm#470, whose isLeafField() check has to call parameters.getEnvironment().getFieldType() and notes this cost as unavoidable today.

Change

• InstrumentationFieldParameters gains a @Nullable GraphQLFieldDefinition and a new constructor (ExecutionContext, @Nullable GraphQLFieldDefinition, Supplier<ExecutionStepInfo>). getField() returns the definition directly when it was supplied and otherwise falls back to the existing supplier path. The existing public constructor is unchanged and delegates with null.
• InstrumentationFieldFetchParameters gains the matching constructor (ExecutionContext, @Nullable GraphQLFieldDefinition, Supplier<DataFetchingEnvironment>, ExecutionStrategyParameters, boolean), and passes the definition to super. getField() is inherited and now returns the eager definition; the getEnvironment() Javadoc points instrumentations that only need the field definition at getField() since it does not build the environment. The existing public constructor is unchanged and delegates with null.
• ExecutionStrategy passes the already resolved fieldDef at both construction sites (beginFieldExecution and beginFieldFetching). These were the only two construction sites in main or test code. SubscriptionExecutionStrategy and DeferredExecutionSupport still use the old constructor as they only hold a step info supplier there.
• getEnvironment() and getExecutionStepInfo() are untouched: they return the same objects and materialise at the same time as before. TracingInstrumentation is not changed in this PR; a follow-up could use getField() there.

Before / after for getField() in beginFieldFetching

So an instrumentation can now do GraphQLTypeUtil.isLeaf(parameters.getField().getType()) on every fetch for free, and only pay for the environment when it actually calls getEnvironment().

Tests

New Spock spec InstrumentationFieldFetchParametersTest:

• getField() with a throwing environment Supplier returns the supplied definition and GraphQLTypeUtil.isLeaf works on it, proving the supplier is never invoked.
• Old constructor still falls back to the supplier (counted, called exactly once).
• Same no-invocation check for InstrumentationFieldParameters with a throwing ExecutionStepInfo supplier.
• End to end: a SimplePerformantInstrumentation reads parameters.getField() in beginFieldFetching against a real schema and sees the right leaf/non-leaf classification per field.

./gradlew test (JDK 25 toolchain):

6076 tests run in 290716 ms
BUILD SUCCESSFUL in 5m 1s

6076 tests, 7 skipped, 0 failures, 0 errors.

🤖 Generated with Claude Code