Skip to content

QuerydslDataFetcher does not preserve the full path prefix for nested parameters #1215

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
zeng-alt opened this issue May 17, 2025 · 1 comment
Assignees
Labels
in: data Issues related to working with data status: backported An issue that has been backported to maintenance branches type: bug A general bug
Milestone

Comments

@zeng-alt
Copy link

Describe the Bug

In org.springframework.graphql.data.query.QuerydslDataFetcher, the private method addParameters(...) fails to preserve the parent path prefix when recursively processing nested input arguments. This leads to incorrect flattening of nested object fields into parameter names.

Expected Behavior

Given a GraphQL query with nested object fields, such as:

query {
  userBy(filter: { profile: { name: "test1" } }) {
    id
  }
}

The expected parameter map should include keys like:

{
  "profile.name": ["test1"]
}

But currently it produces:

{
  "name": ["test1"]
}

The profile. prefix is missing.

Actual Behavior

The path prefix is dropped during recursion because the method call:

addParameters(entry.getKey(), (Map<String, Object>) nested, parameters);

does not incorporate the existing prefix. As a result, only the current key is passed as the new prefix, and the hierarchical path is not preserved.

Affected Code

private void addParameters(
    @Nullable String prefix,
    Map<String, Object> arguments,
    MultiValueMap<String, Object> parameters) {

    for (Map.Entry<String, Object> entry : arguments.entrySet()) {
        Object value = entry.getValue();
        if (value instanceof Map<?, ?> nested) {
            addParameters(entry.getKey(), (Map<String, Object>) nested, parameters); // ❌ This line is incorrect
            continue;
        }
        List<Object> values = (value instanceof List) ? (List<Object>) value : Collections.singletonList(value);
        parameters.put(((prefix != null) ? prefix + "." : "") + entry.getKey(), values);
    }
}

Suggested Fix

Update the recursive call to include the full path:

addParameters(
    (prefix != null ? prefix + "." + entry.getKey() : entry.getKey()),
    (Map<String, Object>) nested,
    parameters
);

This ensures nested paths are flattened correctly into fully qualified keys.

Version

  • spring-graphql: 1.3.4 (or whichever version you're using)
  • Affects: likely all versions since QuerydslDataFetcher was introduced

Impact

This issue causes incorrect behavior when using nested input types (e.g., object fields like profile.name) in queries. It breaks parameter-based filtering when relying on QuerydslBindings.

zeng-alt added a commit to zeng-alt/spring-graphql that referenced this issue May 17, 2025
@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label May 17, 2025
@bclozel bclozel added the in: data Issues related to working with data label May 17, 2025
@rstoyanchev
Copy link
Contributor

The current key is pre-pended at the end of the loop, and we have a test that shows it works for one level of testing. For anything deeper, it is missing the prefix above one level.

@rstoyanchev rstoyanchev added type: bug A general bug and removed status: waiting-for-triage An issue we've not yet triaged labels May 29, 2025
@rstoyanchev rstoyanchev added this to the 1.3.6 milestone May 29, 2025
@rstoyanchev rstoyanchev self-assigned this May 29, 2025
@rstoyanchev rstoyanchev changed the title QuerydslDataFetcher does not preserve path prefix when flattening nested parameters QuerydslDataFetcher does not preserve the full path prefix for nested parameters May 29, 2025
@rstoyanchev rstoyanchev modified the milestones: 1.3.6, 1.4.1 May 29, 2025
@rstoyanchev rstoyanchev added the for: backport-to-1.3.x Marks an issue as a candidate for backport to 1.3.x label May 29, 2025
@github-actions github-actions bot added status: backported An issue that has been backported to maintenance branches and removed for: backport-to-1.3.x Marks an issue as a candidate for backport to 1.3.x labels May 29, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: data Issues related to working with data status: backported An issue that has been backported to maintenance branches type: bug A general bug
Projects
None yet
Development

No branches or pull requests

4 participants