Propagate errors from subgraph without hiding

[ghost]

Apologies if this is not a bug. Our team has invested the better part of a week trying to get this working, and we have been unsuccessful.

Describe the bug We are unable to get the Router to propagate error message from our subgraphs.

In all the following scenarios, we have router config

include_subgraph_errors:
  all: true

We have a service (Service P) which is a subgraph in our supergraph. If we send a query with a bad input directly to the Service P, it returns a helpful response error:

{
    "errors": [
        {
            "message": "UUID cannot parse the given literal of type `StringValueNode`.",
            "path": [
                "input",
                "acceptorId"
            ],
            "extensions": {
                "field": "Foo.acceptorId",
                "fieldType": "UUID"
            }
        }
    ]
}

However if we send the same query to the subgraph via the Router, we get less helpful responses, depending on what Content-Type and Status we return from Service P.

• If Service P returns status 200 and content type application/graphql-response+json; charset=utf-8 or a content-type of application/json, then the response we get from the router is:

  {
  "data": null
  }

  ^ The secondary concern here, is that it doesn't indicate that an error happened at all.

• If Service P returns status 400 and content type application/graphql-response+json; charset=utf-8, then the response we get from the router is:

{
    "data": null,
    "errors": [
        {
            "message": "HTTP fetch failed from 'paymentprocessing': 400: Bad Request",
            "extensions": {
                "code": "SUBREQUEST_HTTP_ERROR",
                "service": "paymentprocessing",
                "reason": "400: Bad Request",
                "http": {
                    "status": 400
                }
            }
        }
    ]
}

In this case, it at least indicates that an error happened, but doesn't have any information as to why, which is a bad experience for our customers who are beginning their integration.

To Reproduce Steps to reproduce the behavior:

1. Any schema on a subgraph behind the router.
2. Return one or more errors from subgraph on request.

Expected behavior I was expecting the errors returned by the subgraph to be included in the response from the router.

Desktop (please complete the following information):

• We run Router in a docker container on a Arm64 Linux container.

Additional context

• tested on multiple version of Router, including the latest 1.48.1
• include_subgraph_errors is set for all subgraphs
• We tried different combinations of status codes and content types for the subgraph response.

Workarounds? We are also interested in work arounds if anyone can provide direction for that. We already have a couple small Rhai scripts running in production, and are able to add another if required.

Thank you in advanced.

[abernix]

This sounds like it could be potentially a bug. Do you know if there were any previous versions of the Router that didn't cause this? And is it possible for you to provide a runnable reproduction?

[ghost]

I can check our Git history, but I believe its at least been since version ~1.36. I will also try to create a minimally reproducible example thats executable. Might need a couple days to find the time though. Thank you for the reply.

[ghost]

Okay I set up a repository here: https://github.com/matt-tesouro/graphql-incorrect-error-propagation

Startup and commands are in the readme, along with the responses I get. Basically:

1. docker-compose up -d
2. Curl commands for getting responses from subgraph directly.
3. Curl commands for getting responses through Router.

If for some reason you want to update the schemas, both subgraphs are in the root directly, and you can recompose them using the command in the readme.

[alhabibhasan]

I'm coming across a similar issue where setting the config to:

include_subgraph_errors:
  subgraphs:
    api-xxxx: true

Doesn't seem to have any impact on the response and error messages are always redacted.

[fl-chris-altamimi]

This is a serious issue for us - Would love to get more eyes on this if possible.