GraphQlArgumentBinder silently drops fields from extended input types for nested input objects #1418

Activity

1. spring-projects-issues

   added

   status: waiting-for-triageAn issue we've not yet triagedAn issue we've not yet triaged

   on Jan 31, 2026
2. bclozel commented on Mar 13, 2026

   

   bclozel

   on Mar 13, 2026

   Member

   More actions

   Hello @salbecknm and thanks for reaching out. Sorry for the delayed response. I imported the (very useful) sample application that you provided, and I would like your perspective on a couple of points.

   Type extension in GraphQL

   First, as far as I understand, the following GraphQL schema means that we are extending AddressInput with a new field, and that there is no way for us to consider AddressInput without its zipCode field. If the field is missing, it's considered null.

   input AddressInput {
     street: String
   }
   
   extend input AddressInput {
     zipCode: String
   }

   I validated this point by making zipCode: String! and sending an input without the zipCode field.

   ExtendedAddressInput and AddressInput

   In this context, I fail to understand the need for both ExtendedAddressInput and AddressInput. By itself, there is no use for AddressInput, is there? Updating your sample application in a way that UserInput has ExtendedAddressInput as a field makes the whole thing work.

   In general, Spring for GraphQL needs to discover types in some ways. We are not scanning the entire classpath, but rather finding out about Java types in two ways:

   • finding types in controller method signatures
   • deriving type names from the schema and trying to locate them on the classpath along other Java types used for the schema.

   With your sample application, I can't find a way for Spring to figure out why that Java type should be used in the first place. I'm sure there are good reasons for this setup and that those are omitted for simplicity, but it would be useful for us to better understand this use case and when/why we should expect such setups.

   Thanks!
3. bclozel

   added

   status: waiting-for-feedbackWe need additional information before we can continueWe need additional information before we can continue

   on Mar 13, 2026
4. salbecknm commented on Mar 15, 2026

   

   salbecknm

   on Mar 15, 2026

   Author

   More actions

   Thank you for looking into this.

   You are correct, after extend input, the GraphQL schema has a single merged type. The extend keyword is a schema-authoring mechanism, and at runtime there is no distinction between the original fields and the extended ones.

   The use case driving this is modular schema composition. Consider a reusable core module (published as a JAR, used across multiple projects) that defines a mutation and its input type:

   # Core module schema
   input UpdateCartOperation {
     setPaymentMethod: SetPaymentMethod
     setShippingAddress: SetShippingAddress
     # ... other standard operations
   }
   
   input UpdateCartInput {
     cartId: ID!
     ops: [UpdateCartOperation!]!
   }
   
   type Mutation {
     cart_update(input: UpdateCartInput!): UpdateCartResult
   }

   A specific project needs to add a client-specific command — say, setComment — that doesn't belong in the core module because it's not useful to other consumers. The GraphQL spec provides extend input precisely for this:

   # Project-specific schema
   extend input UpdateCartOperation {
     setComment: SetComment
   }

   On the Java side, the project extends the core class to add the new field. The core mutation handler continues to work unchanged. Only the new command requires new code. This is the modularity benefit that extend input enables at the schema level.

   The problem is that Spring GraphQL's argument binding resolves the Java class from the method signature (or field type), which points to the core class. There is no mechanism for the binding to use a project-specific subclass instead. Extended fields are silently dropped because the base class has no matching property.

   An implemented workaround on our side

   We have worked around this issue using an annotation-based approach:

   1. An @ExtendedGraphQLInput(baseType = ...) annotation that the project-specific subclass declares:

   // In project-specific code
   @ExtendedGraphQLInput(baseType = UpdateCartOperation.class)
   public class ProjectUpdateCartOperation extends UpdateCartOperation {
       private SetComment setComment;
       // getter/setter
   }

   2. A registry that discovers annotated classes at startup, validates that the annotated class actually extends the declared base type, and builds a baseType -> extendedType mapping.

   3. In GraphQlArgumentBinder.bindMap, before resolving the input, the binder checks the registry. If a mapping exists for targetClass, it substitutes the extended class and its ResolvableType, so the correct subclass is instantiated and all fields (including the extended ones) are bound.

   The change to the binder itself is minimal, a single lookup before the existing BeanUtils.getResolvableConstructor(targetClass) call. The rest of the binding logic (constructor binding, setter binding) works unchanged because the subclass inherits the base class properties.

   We also explored extending GraphQlArgumentBinder.Options to support custom type mappings, but pursuing it from our side required overriding too many Spring internals to be practical. That said, if you see it as the right direction, it may be a cleaner fit implemented within Spring itself.

   Happy to contribute a PR for whichever direction you prefer.
5. spring-projects-issues

   added

   status: feedback-providedFeedback has been providedFeedback has been provided

   and removed

   status: waiting-for-feedbackWe need additional information before we can continueWe need additional information before we can continue

   on Mar 15, 2026
6. bclozel commented on Mar 18, 2026

   

   bclozel

   on Mar 18, 2026

   Member

   More actions

   Thanks for your feedback. I somehow got stuck on that part:

   On the Java side, the project extends the core class to add the new field. The core mutation handler continues to work unchanged. Only the new command requires new code. This is the modularity benefit that extend input enables at the schema level.

   How is that core mutation handler shipped? Is that an interface that you must implement or an actual implementation?
   In both cases, I would argue that if you update the core class you should also update the mutation method to reflect the type changes.

   I can understand that this might be a strong requirement on your side, but I don't think that this is a use case we would address in Spring for GraphQL. At best, we could consider updating the GraphQlArgumentBinder with additional protected methods to allow extension.
7. bclozel

   added

   status: waiting-for-feedbackWe need additional information before we can continueWe need additional information before we can continue

   and removed

   status: feedback-providedFeedback has been providedFeedback has been provided

   on Mar 18, 2026
8. bclozel

   self-assigned this

   on Mar 18, 2026
9. salbecknm commented on Mar 19, 2026

   

   salbecknm

   on Mar 19, 2026

   Author

   More actions

   Thanks for the fast reply and for the suggestion to make GraphQlArgumentBinder methods protected, that would be very welcome and would allow us to implement the subclass resolution cleanly without patching framework internals. We'd appreciate that. Happy to test against a snapshot if you'd like direct feedback.

   To answer your question about how the core mutation handler is shipped, it is an actual implementation. We built a framework for large CRUD GraphQL APIs (CMS, cart management) that follows a CQRS pattern where all mutation inputs are command trees. The mutation handler traverses the tree and for each command node, dispatches to a specific executor determined by the command type. It also handles generic concerns like validation and persisting the result. The handler itself is command-agnostic. it never references specific command types, which is why it doesn't need to change when new commands are added.

   Before extend input existed in GraphQL, we offered generic SetCustomAttribute commands, essentially name: String, value: Any. Using that projects could add custom fields like a comment to the cart example from my previous reply. The project code and the client would agree on the attribute name, making it an implicit part of the API. It worked, but it was loosely typed, easy to break and not self-documenting.

   With extend input, a project can instead add a strongly typed setComment: SetComment command and define a SetCommentCommandExecutor that handles it during tree traversal. The return type is also extended with a new field comment and a resolver. The result is strong typing and an explicit API, a significant improvement over the generic attribute approach.

   The reason updating the mutation method doesn't help here is the nesting. The extended command sits inside UpdateCartOperation, which sits inside UpdateCartInput. To change the Java type of setComment's container, we'd need to override UpdateCartOperation, then UpdateCartInput (because it references UpdateCartOperation), and then the mutation method signature, essentially duplicating the entire path from root to the extended leaf. This is exactly the boilerplate that extend input eliminates at the schema level.
10. spring-projects-issues

    added

    status: feedback-providedFeedback has been providedFeedback has been provided

    and removed

    status: waiting-for-feedbackWe need additional information before we can continueWe need additional information before we can continue

    on Mar 19, 2026