Race condition in header propagation for multi-field federation queries causes subgraphName to be undefined

[rowanparker]

There is a race condition in the header propagation system when executing multi-field GraphQL queries that span multiple subgraphs
in federation mode. The fromClientToSubgraphs function receives subgraphName: undefined during parallel execution, causing
authentication failures for queries with multiple top-level fields.

Steps to Reproduce

1. Set up a federated GraphQL gateway with multiple subgraphs
2. Configure header propagation using fromClientToSubgraphs
3. Execute a query with multiple top-level fields from different subgraphs:

  query MultiFieldQuery {
    userProfile {    # From UserService subgraph
      id
      name
    }
    products {       # From ProductService subgraph
      id
      title
    }
  }

4. Observe that subgraphName parameter is undefined in the fromClientToSubgraphs function

Expected Behavior

The fromClientToSubgraphs function should receive the correct subgraphName for each subgraph request, allowing for
subgraph-specific header propagation.

Actual Behavior

• Single-field queries work correctly (subgraphName is properly set)
• Multi-field queries fail with subgraphName: undefined
• Authentication headers are not properly propagated to subgraphs

Environment

• @graphql-hive/gateway: 1.15.4
• @graphql-mesh/fusion-runtime: 0.11.17
• Node.js: 18+

Root Cause Analysis

Based on source code analysis, this is a race condition between two hook execution flows:

1. Header Propagation Flow

File: @graphql-hive/gateway-runtime/dist/index.js:1183
const subgraphName = executionRequest && subgraphNameByExecutionRequest.get(executionRequest);

2. Subgraph Execution Flow

File: @graphql-mesh/fusion-runtime/dist/index.js:929
subgraphNameByExecutionRequest.set(executionRequest, subgraphName);

The Race Condition

1. The subgraphNameByExecutionRequest WeakMap is populated in onSubgraphExecute()
2. Header propagation tries to read from this WeakMap in onFetch()
3. During federation parallel execution, onFetch() is called BEFORE onSubgraphExecute()
4. This causes subgraphNameByExecutionRequest.get() to return undefined

Why Single-field Queries Work

Single-field queries use sequential execution where timing is deterministic and onSubgraphExecute() populates the WeakMap before
onFetch() reads it.

Why Multi-field Queries Fail

Multi-field queries create parallel execution contexts where the timing becomes non-deterministic, leading to the race condition.

Workaround

  const propagateHeadersFromClientToSubgraphs = ({ request, subgraphName }) => {
    const headers = {};

    // Handle race condition where subgraphName is undefined
    if (!subgraphName) {
      console.warn('[Race Condition] subgraphName undefined in multi-field query');
      // Propagate all necessary headers as fallback
      const fallbackHeaders = ['authorization', 'cookie', 'origin'];
      fallbackHeaders.forEach((name) => {
        const value = request.headers.get(name);
        if (value) {
          headers[name] = value;
        }
      });
      return headers;
    }

    // Normal subgraph-specific header logic
    // ... rest of implementation
  };

Proposed Solution

The issue requires fixing the hook execution order to ensure that:

1. subgraphNameByExecutionRequest.set() is called before fromClientToSubgraphs()
2. Or provide an alternative mechanism to reliably identify the target subgraph during header propagation

This appears to be a fundamental architectural issue requiring coordination between @graphql-hive/gateway-runtime and
@graphql-mesh/fusion-runtime.

Additional Context

This issue has been confirmed to persist across multiple versions (1.15.1 through 1.15.4) and affects any federation setup using
multi-field queries with header propagation.

[EmrysMyrddin]

Hi! Thank you for submitting this issue with a lot of details!
Sadly, I didn't managed to reproduce this behavior.

Do you think you could share more about your setup? Or even better a minimal reproduction repository ?

You can also submit a PR with a failing test. I've tried to make a new e2e test to trigger this bug, but I failed: #1313

[EmrysMyrddin]

I've successfully reproduced the issue! The problem is not a race condition, but a bug with operation batching.

When multiple fields for the same subgraph are resolvable in parallel, they get batched in a single request. This generates a new ExecutionRequest, which contains the merge of all relevant execution requests. This "merged request" is not added to the subgraphNameByExecutionRequest you identified.

We are working on a fix :-) Thank you again for pointing it!

[EmrysMyrddin]

Can you please try this alpha version to confirm that is fixes your issue?
@graphql-hive/gateway@1.15.5-alpha-76145a95bccf4df5b60cf9253177ce2e2e0250d4

[rowanparker]

@EmrysMyrddin Thank you for the quick reply. Unfortunately that fix didn't work. I'm still not getting the subgraphName value coming through. It now also seems to be missing on single fields as well.

1.15.5-alpha-76145a95bccf4df5b60cf9253177ce2e2e0250d4

Two fields

One field

1.15.4

Two fields

Broken as above

One field

[EmrysMyrddin]

Oh, that's weird, I've even added a test to make sure it actually fixed it.

Perhaps there is a problem with a transitive dependency that is not using the snapshot version?

[EmrysMyrddin]

Or perhaps the subgraph name is not detected properly, can you share your gateway configuration file?