Repository navigation
Server shouldn't look for a parameterized @external resolver method #781
Description
Issue Description
Take a look at the following example in the Apollo documentation.
Currently, the server would expect a set of classes as follows:
class Product {
id, shippingEstimate; // lazy shorthand
}
interface IQueryResolver {
Product someRootResolver(...);
}
interface IProductResolver {
Integer weight(Product product);
}
But it should not expect a separate resolver method for the weight field since it is marked @external, meaning this subgraph cannot resolve it. Instead, it should just expect a plain old weight field as part of the Product class, and assume that some other subgraph will resolve it:
class Product {
id, weight, shippingEstimate; // lazy shorthand
}
interface IQueryResolver {
Product someRootResolver(...);
}
The field is needed so that the entity resolver can fill in the result of the external weight resolver into the Product model, and also so that this subgraph can read it during subsequent query processing.
Activity
oryan-block commentedon Oct 18, 2026
Closing as not planned. graphql-java-tools doesn't know about federation directives, and a property can't take arguments, so a field with arguments needs a method. You can add
getWeight(String units)toProduct, or set amissingResolverDataFetcherProviderthat reads the property for@externalfields and still fails the build for anything else:It also works with Fed 2
@linkimports whenallowUndeclaredDirectives(true)is set.