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

[salbecknm]

Description

Spring GraphQL correctly accepts and validates GraphQL input type extensions (extend input) at schema level.
However, when an extended input type is used nested inside another input object, the additional fields introduced by the extension are silently dropped during runtime binding.
This results in GraphQL input that is:

• valid according to the schema,
• but partially inaccessible from Java code.

This behavior makes input extensions effectively unusable for nested input types.

Actual Behavior

Given the following schema:

input AddressInput {
  street: String
}

extend input AddressInput {
  zipCode: String
}

input UserInput {
  name: String
  address: AddressInput
}

type Mutation {
  createUser(input: UserInput!): Boolean
}

And Java models:

class AddressInput {
  private String street;
}

class ExtendedAddressInput extends AddressInput {
  private String zipCode;
}

class UserInput {
  private AddressInput address;
}

Executing the mutation:

mutation {
  createUser(input: {
    name: "John",
    address: {
      street: "Main St",
      zipCode: "12345"
    }
  })
}

then the following occurs

• Schema validation succeeds.
• Execution proceeds without errors.
• At runtime, UserInput.address is always bound as AddressInput.
• The zipCode field is silently ignored and cannot be accessed.
• No error or warning is raised.

Reproduction

A minimal Maven project ZIP is attached. To reproduce:

spring-graphql-input-extension-demo.zip

1. Import the project
2. Run the test GraphQlInputExtensionTest
3. The test fails, demonstrating that a field defined via extend input is accepted by the schema but not bound to the Java input object at runtime.

Current workaround:
I implemented a local workaround that makes the extended input fields available at runtime, which confirms that the issue is confined to argument binding.
The workaround requires replacing internal framework classes and is therefore not suitable as a long-term solution.
I can provide details of the workaround, including the implementation, if that would be helpful.

[bclozel]

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!