connectionParams are not passed downstream anymore

[alexlag]

Issue workflow progress

Progress of the issue based on the Contributor Workflow

• 1. The issue provides a reproduction available on Github
• 2. A failing test has been provided
• 3. A local solution has been provided
• 4. A pull request is pending review

---

Describe the bug

After packages upgrade connectionParams is empty on server behind the mesh with graphql-ws protocol.

With "@graphql-mesh/graphql": "^0.27.0" server receives empty connectionParams.
On "@graphql-mesh/graphql": "^0.20.6" mesh passed down headers extracted with operationHeaders (introduced in #2642).
Attaching extra headers to current request seems to be useless now.

My research showed, that graphql handler used to pass headers: headersFactory(resolverData) to urlLoader.getExecutorAsync (essentially creating proper headers values on ws connection) and now it's in extensions for executor call. And I think original request with its headers is not available anymore on execution step.

To Reproduce
Steps to reproduce the behavior:

I made a small repo to reproduce.

Expected behavior

Honestly, not so sure, what is a proper behavior here.

Environment:

• OS: MacOSX 11.6.6
• "@graphql-mesh/cli": "^0.73.1"
• "@graphql-mesh/graphql": "^0.27.0"
• NodeJS: v14.19.3

Additional context

I am just looking for a way to pass auth info with socket connection

[enisdenjo]

Short ping for @alexlag, after #4304 lands the headers will be passed downstream as a part of the GraphQL operation extensions.

The following modification to your repro repo (in onSubscribe implementation (here)) is necessary to access the upstream headers:

-        const { schema, execute, subscribe, contextFactory, parse, validate } =
-          yogaApp.getEnveloped(ctx);
+        const { schema, execute, subscribe, contextFactory, parse, validate } =
+          yogaApp.getEnveloped({
+            ...ctx,
+            upstreamHeaders: msg.payload.extensions?.headers,
+          });

And then in the subscribe resolver (here) you can access the headers through: context.upstreamHeaders.

Not very clean, I agree - we will think about improving upon this in the future, see #4305.