Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

consistent error responses #2101

Open
deweyjose opened this issue Nov 14, 2022 · 2 comments
Open

consistent error responses #2101

deweyjose opened this issue Nov 14, 2022 · 2 comments

Comments

@deweyjose
Copy link
Contributor

Describe the bug
We see different error response shape depending on which router lifecycle event generates an error.

Sometimes the response body will have an errors[0].extensions.type, others will not.

To Reproduce

Invalid Variables:

request:
query

query node($nodeId: ID!) {
  node(id: $nodeId) {
    ... on DemoBook {
      bookId
    }
  }
}
variables
{
	"nodeId": null
}

response:
400

{"errors":[{"message":"invalid type for variable: 'nodeId'","extensions":{"type":"ValidationInvalidTypeVariable","name":"nodeId"}}]}

we see traces and metrics for this event. we do not observe logs for this event. I actively tailed the K8s logs while running a small test in production and ran locally.

No Query String

request:

response:
400

{"data":null,"errors":[{"message":"Must provide query string."}]}

we do NOT see traces or metrics for this event. we do not observe logs for this event. I actively tailed the K8s logs while running a small test in production and ran locally.

Invalid Query String

request:

Book {\n      boo }\n}

response:
400

{"errors":[{"message":"parsing error: ERROR@0:4 \"expected definition\" Book"}]}

we see traces and metrics for this event. we do not observe logs for this event. I actively tailed the K8s logs while running a small test in production and ran locally.

Expected behavior

  • all error conditions covered in prometheus metrics.
  • all error response to have the same shape regarding extensions.type

Output
If applicable, add output to help explain your problem.

Desktop (please complete the following information):

  • OS: [e.g. iOS]
  • Version [e.g. 22]

Additional context
Add any other context about the problem here.

@abernix
Copy link
Member

abernix commented Nov 22, 2022

Definitely agree there's some work to do here, and thanks for opening this!

Just to call out one thing I see here already, this shouldn't have data present since it happened before execution started, per spec:

{"data":null,"errors":[{"message":"Must provide query string."}]}

bnjjj added a commit that referenced this issue Nov 25, 2022
Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
@bnjjj
Copy link
Contributor

bnjjj commented Nov 28, 2022

I think we should be consistent with what apollo-server is doing about errors. https://www.apollographql.com/docs/apollo-server/data/errors/

bnjjj added a commit that referenced this issue Dec 15, 2022
related to #2101 
This is a draft/attempt to have more consistent errors in the router
following this spec
https://www.apollographql.com/docs/apollo-server/data/errors/ with the
error extension code.

Signed-off-by: Benjamin Coenen <5719034+bnjjj@users.noreply.github.com>
@abernix abernix modified the milestone: v1.7.0 Dec 22, 2022
@abernix abernix removed this from the v1.7.0 milestone Jan 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants