Getting no response when pointing at multiple graphql servers with operationHeaders.

[Davenporten]

So I've been working with graphql-mesh for a little while now and a problem just popped up that I don't really understand. So I've tried to parse down my .meshrc to the bare minimum:

require:
  - "ts-node/register/transpile-only"
serve:
  playground: true
sources:
  - name: "server1"
    handler:
      graphql:
        endpoint: http://localhost:5001
        operationHeaders:
          Authorization: "{context.headers['authorization']}"
  - name: "server2"
    handler:
      graphql:
        endpoint: http://localhost:5000
        operationHeaders:
          Authorization: "{context.headers['authorization']}"

and my config is

    "@graphql-mesh/cli": "^0.35.1",
    "@graphql-mesh/graphql": "^0.18.7",
    "@types/node": "^16.4.10",
    "dataloader": "^2.0.0",
    "dotenv": "^10.0.0",
    "graphql": "^15.5.1",
    "graphql-scalars": "^1.10.0",
    "graphql-tag": "^2.12.5",
    "ts-node": "^10.0.0",
    "typescript": "^4.3.5"

on Windows 10.
When I build this on my actual graphql servers with

yarn mesh build --output ./src/generated/mesh.ts --require dotenv/config

I get

...
Mesh - StitchingMerger: Fetching Apollo Federated Service SDL for server1
Mesh - StitchingMerger: Fetching Apollo Federated Service SDL for server2
Mesh: invalid json response body at https://_server2_/graphql reason: Unexpected ''
Mesh: {
  message: "invalid json response body at https://_server2_/graphql reason: Unexpected ''",
  type: 'invalid-json',
  name: 'FetchError',
  stack: "FetchError: invalid json response body at https://_server2_/graphql reason: Unexpected ''\n" +        
    '    at ...\\node_modules\\node-fetch\\lib\\index.js:272:32\n' +
    '    at processTicksAndRejections (internal/process/task_queues.js:93:5)\n' +
    '    at async ...\\node_modules\\@graphql-mesh\\merger-stitching\\index.js:105:45\n' +
    '    at async Object.getWithSet (...\\node_modules\\@graphql-mesh\\store\\index.js:144:38)\n' +
    '    at async ...\\node_modules\\@graphql-mesh\\merger-stitching\\index.js:100:36\n' +
    '    at async Promise.all (index 0)\n' +
    '    at async StitchingMerger.getUnifiedSchema (...\\node_modules\\@graphql-mesh\\merger-stitching\\index.js:91:9)\n' +
    '    at async Object.getMesh (...\\node_modules\\@graphql-mesh\\runtime\\index.js:105:25)\n' +
    '    at async Object.handler (...\\node_modules\\@graphql-mesh\\cli\\bin.js:936:53)'
}

Now if I take out one of the handlers, it works. If I take out the operationHandlers it works on both handlers, it works.

The endpoints that my graphql-mesh instance is pointed at are pretty big and complex, so I tried pointing it a extremely simple, basically identical servers:

const { ApolloServer, gql } = require('apollo-server');

// A schema is a collection of type definitions (hence "typeDefs")
// that together define the "shape" of queries that are executed against
// your data.
const typeDefs = gql`
  # Comments in GraphQL strings (such as this one) start with the hash (#) symbol.

  # This "Book" type defines the queryable fields for every book in our data source.
  type Book {
    title: String
    author: String
  }

  # The "Query" type is special: it lists all of the available queries that
  # clients can execute, along with the return type for each. In this
  # case, the "books" query returns an array of zero or more Books (defined above).
  type Query {
    books: [Book]
  }
`;

const books = [
  {
    title: 'The Awakening',
    author: 'Kate Chopin',
  },
  {
    title: 'City of Glass',
    author: 'Paul Auster',
  },
];

// Resolvers define the technique for fetching the types defined in the
// schema. This resolver retrieves books from the "books" array above.
const resolvers = {
  Query: {
    books: () => books,
  },
};

// The ApolloServer constructor requires two parameters: your schema
// definition and your set of resolvers.
const server = new ApolloServer({ typeDefs, resolvers });

// The `listen` method launches a web server.
server.listen({port: 5001}).then(({ url }) => {
  console.log(`🚀  Server ready at ${url}`);
});

and

const { ApolloServer, gql } = require('apollo-server');

// A schema is a collection of type definitions (hence "typeDefs")
// that together define the "shape" of queries that are executed against      
// your data.
const typeDefs = gql`
  # Comments in GraphQL strings (such as this one) start with the hash (#) symbol.

  # This "Post" type defines the queryable fields for every post in our data source.
  type Post {
    title: String
    author: String
  }

  # The "Query" type is special: it lists all of the available queries that   
  # clients can execute, along with the return type for each. In this
  # case, the "posts" query returns an array of zero or more Posts (defined above).
  type Query {
    posts: [Post]
  }
`;

const posts = [
  {
    title: 'The Awakening',
    author: 'Kate Chopin',
  },
  {
    title: 'City of Glass',
    author: 'Paul Auster',
  },
];

// Resolvers define the technique for fetching the types defined in the       
// schema. This resolver retrieves posts from the "posts" array above.        
const resolvers = {
  Query: {
    posts: () => posts,
  },
};

// The ApolloServer constructor requires two parameters: your schema
// definition and your set of resolvers.
const server = new ApolloServer({ typeDefs, resolvers });

// The `listen` method launches a web server.
server.listen({port: 5000}).then(({ url }) => {
  console.log(`🚀  Server ready at ${url}`);
});

and the build worked. In fact, the Mesh - StitchingMerger: Fetching Apollo Federated Service SDL for ... doesn't even come up. So there must be something in the schemas for my actual graphql servers (and I can't share them here) that is requiring this step to be run. But even if it runs I don't understand why there is no response. The query that is being run is

query __ApolloGetServiceDefinition__ {
    _service {
      sdl
    }
  }

and this returns fine when run in the playground.

[ardatan]

Could you create an issue with this reproduction on CodeSandbox? So we can move on better :)

[Davenporten]

I can make a sandbox with my simple implementation, but it doesn't reproduce the problem.

[ardatan]

Do you have anything related to federation in your configuration?

[Davenporten]

No, and I've removed any packages in my package.json relating to federation or anything really besides @graphql-mesh/cli and @graphql-mesh/graphql. And when I'm using the simpler graphql servers I don't run into the problem, which makes me think that there is something about the schemas coming back from the servers that is making my graphql-mesh instance want to do that step.

[Davenporten]

@ardatan So I think I've found the root problem, but I'm not sure of the solution. So I set

        operationHeaders:
          Authorization: "{context.headers['authorization']}"

I debugged how Authorization is getting set and really drilled down and when it comes to this line

applyData(key, data) {
    return (0, _lodash.get)(data, key);
  }

in string-interpolation the context is undefined:

Is there something you think I might be doing wrong, or maybe a different place to look for these headers?

[Davenporten]

This seems to be directly related to #1459