Timed out subgraph requests do not trigger SubgraphResponse coprocessor requests

[lleadbet]

Describe the bug

Given a subgraph that times out using the traffic_shaping plugin, it will not trigger a request to a coprocessor for the SubgraphResponse stage.

This seems related to #4590, but for the subgraph hooks.

To Reproduce

Enable an arbitrarily low timeout and a coprocessor enabled:

traffic_shaping:
  all:
    timeout: 500ms
    
coprocessor:
  url: http://localhost:4040
  timeout: 20s 
  supergraph:
    request:
      headers: true
      body: true
    response:
      headers: true
      body: true
  subgraph:
    all:
      request: 
        headers: true 
        body: true
      response: 
        headers: true
        body: true

And have a subgraph that forces the timeout, you'll get the logs noted in Output.

Expected behavior

To get a SubgraphResponse request to the coprocessor.

Output

Example response from router:

{
  "data": {},
  "errors": [
    {
      "message": "HTTP fetch failed from '2': request timed out",
      "path": [],
      "extensions": {
        "code": "SUBREQUEST_HTTP_ERROR",
        "service": "2",
        "reason": "request timed out"
      }
    }
  ]
}

Log out from coprocessor for debugging:

SupergraphRequest
{
  accept: 'application/json',
  'content-type': 'application/json',
  host: 'localhost:4040',
  'content-length': '1859'
}
SubgraphRequest
{
  accept: 'application/json',
  'content-type': 'application/json',
  host: 'localhost:4040',
  'content-length': '1689'
}
SupergraphResponse
{
  accept: 'application/json',
  'content-type': 'application/json',
  host: 'localhost:4040',
  'content-length': '835'
}

Where it emits the stage + headers.

Desktop (please complete the following information):

• OS: macOS
• Version: 1.43.1

Additional context

SupergraphResponse does trigger.

The aim of this specific situation is to enable circuit breaking via coprocessor, but without knowing the status of requests to subgraphs, it's nontrivial to track if a response comes back or not for a given request. Firing back with the errored message would trivialize this.

[Geal]

as said in chat: this is probably due to the timeout returning a Err<BoxError> instead of a Ok<subgraph::Response> containing the error, because then the coprocessor plugin transmits the error directly instead of passing it through the coprocessor

[IvanGoncharov]

Fixed in #5578