willSendRequest and didReceiveResponse arg request are not the same type

Per the documentation, the types of the argument “request” of functions willSendRequest and didReceiveResponse are the same

But in practice they are different:

willSendRequest request

{
  query: 'query GetServiceDefinition { _service { sdl } }',
  http: {
    method: 'POST',
    url: 'http://localhost:4001/graphql',
    headers: Headers { [Symbol(map)]: [Object: null prototype] }
  }
}

didReceiveResponse request

Request {
  size: 0,
  timeout: 0,
  follow: 20,
  compress: true,
  counter: 0,
  agent: undefined,
  [Symbol(Body internals)]: {
    body: <Buffer 7b 22 71 75 65 72 79 22 3a 22 71 75 65 72 79 20 47 65 74 53 65 72 76 69 63 65 44 65 66 69 6e 69 74 69 6f 6e 20 7b 20 5f 73 65 72 76 69 63 65 20 7b 20 ... 9 more bytes>,
    disturbed: false,
    error: null
  },
  [Symbol(Request internals)]: {
    method: 'POST',
    redirect: 'follow',
    headers: Headers { [Symbol(map)]: [Object: null prototype] },
    parsedURL: Url {
      protocol: 'http:',
      slashes: true,
      auth: null,
      host: 'localhost:4001',
      port: '4001',
      hostname: 'localhost',
      hash: null,
      search: null,
      query: null,
      pathname: '/graphql',
      path: '/graphql',
      href: 'http://localhost:4001/graphql'
    },
    signal: null
  }
}

So now on a gateway/federation that produces multiple such calls, it seems impossible to correlate which request corresponds to which response, because the context argument given is shared between all requests/responses.

In practice I am trying to integrate jaegertracing to an apollo gateway for a dynamic demo, so I want to start spans in willSendRequest, and finish them in didReceiveResponse. So for now I can only start+finish them in willSendRequest, which is not as nice. Maybe there is a more magical/builtin way to do it?

Thank you.

[abernix]

@ecourreges-orange I only just picked up this issue since @CreatCodeBuild’s recent comment it, however I opened #3743 just a few hours before it came in. At the very least, I think the original issue that you reported will be fixed by it. Please let me know if you agree. However, we certainly don’t switch to a nested tree-structure pattern — which is what, e.g. the Apollo Server Plugins (note, not the same for @apollo/gateway) try to offer as you can see in apollo-server-plugin-base.

@CreatCodeBuild It’s worth noting that you could probably leverage some of the tracing data that Apollo Reporting already gathers since we use that to generate the distributed tracing data from Apollo Gateway (and downstream implementing services). Those metrics are already used to power the Apollo Graph Manager metrics experience, seen at approximately this point in this video. Overall, I suspect you’ll get much more helpful accuracy in the tracing by utilizing the actual resolve timings from the downstream services rather than merely gathering request start and response finish.

[abernix]

I’ve merged the fix for this in #3743 into the release branch (#3763) for the next version of @apollo/gateway. While that PR is title with the version of Apollo Server that it aligns with, this will be in an eventual @apollo/gateway@0.13.0. Currently, the alpha release is already published as 0.13.0-alpha.0, which is available on the next tag. Do note that this is a breaking change and read the above PR for details! 😉

npm install @apollo/gateway@0.13.0-alpha.0

Thanks so much for reporting this originally, @ecourreges-orange!