Fusion ResolveByKeyBatch query composed with unused argument

[aidy-jenkins]

Product

Hot Chocolate

Version

14.3

Link to minimal reproduction

https://github.com/aidy-jenkins/FusionIssueReproduction/tree/unused-lookup-argument

Steps to reproduce

If I have a publicly available resolver with an optional filter which is unused and a subgraph with an internal lookup on the same field, Fusion composes the subgraph query incorrectly.

# Subgraph 1
type Query {
	foos("Optional filter" ids: [Int!]): [Foo!]
}

type Foo { 
...

# Subgraph 2
type Query {
	foosById(ids: [Int!]!): [Foo!] @lookup @internal
}

type Foo {
	id: Int!
	bar: Bar!
}
...

Compose the Fusion schema and try to query it:

query GetFoosAndBars {
  foos {
    id
    bar {
      id
    }
  }
}

What is expected?

The Fusion Gateway should send a query to the first subgraph to resolve foos and then use the internal lookup on the second subgraph to resolve bar

query GetFoosAndBars_2($__fusion_exports__1: [Int!]!) { foosById(ids: $__fusion_exports__1) { bar { id } __fusion_exports__1: ids } }

What is actually happening?

Inspecting the query plan, we can see that it has generated a query to the first subgraph to retrieve the Ids into a variable, it then passes this variable to the second subgraph but does not use it in the query, which results in validation errors from the second subgraph:

1. that the argument $__fusion_exports__1 is unused
2. that the foosById resolver is missing its required ids argument

Relevant log output

Additional context

Note that if we use a different resolver to retrieve Foo e.g. fooByName, then the composed query works correctly.
Also if we provide a value to the top level resolver then it also works as expected.

I'm guessing the Fusion Gateway is getting confused (possible by the parameter name) and mistakenly composes the query to the second subgraph as it does the first subgraph.