-
Notifications
You must be signed in to change notification settings - Fork 272
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
Request timeout and rate limited error responses are structured errors #5578
Conversation
This comment has been minimized.
This comment has been minimized.
CI performance tests
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it might also be interesting to add more tests for metrics, like is it properly accounted with the right status code and so one
@bnjjj I added metrics into integration tests, please take a look |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not a blocker, but if you have time could you add a test including configuration with custom telemetry and adding the status_code attributes on http.server.request.duration
?
Something like:
telemetry:
instrumentation:
instruments:
router:
http.server.request.duration:
attributes:
# Standard attributes
http.response.status_code: true
graphql.error:
on_graphql_error: true
Make sure to guard it like here and test it with the right env variables set to enable graphos in tests (TEST_APOLLO_KEY
, TEST_APOLLO_GRAPH_REF
).
Request timeout (
408 Request Timeout
) and request rate limited (429 Too Many Requests
)errors will now result in a structured GraphQL error (i.e.,{"errors": [...]}
) being returned to the client rather than a plain-text error as was the case previously.Also both errors are now properly tracked in telemetry, including
apollo_router_graphql_error_total
metric.Checklist
Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review.
Exceptions
Note any exceptions here
Notes
Fixes: #4891
Footnotes
It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. ↩
Configuration is an important part of many changes. Where applicable please try to document configuration examples. ↩
Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions. ↩