Background
We gather information about GraphQL requests that contain an error response (errors key is present within the GraphQL response).
This information is used to display the success and failure rate of GeaphQL request within the Hive Console dashboard, insight view.
Total failure rate
Failure rate compared to success rate
Failure rate by operation
A common practice is to use the code property within the error extensions to identify the origin of the error.
E.g. if a access token sent to a GraphQL API is expired, the following response could be interpreted by the frontend client for refreshing the access token.
{
"errors": [
{
"message": "AccessToken expired",
"extensions": { "code": "NEEDS_REFRESH" }
}
]
}Or if a request was made without an access token, the following response could be interpreted by the frontend client for showing a log-in form.
{
"errors": [
{
"message": "AccessToken expired",
"extensions": { "code": "UNAUTHENTICATED" }
}
]
}Apollo Server initially popularized this pattern and has become an unofficial standard for handling arbitrary errors that are not defined using the Schema SDL.
Task Overview
Users of Hive want to see the reason the reason on why the execution of a request failed without using additional tools. An enhancement would be to include the error code(s) within the usage reporting.
The following things need to be done:
- Adjust usage service to support sending error codes to the usage reporting API for the v2 protocol
- Adjust the Hive SDKs for extracting the error codes from an error response and include them in the JSON payload sent to the usage reporting API (also include a way to customize the extraction of the error codes; sending error codes should be opt-in)
- Figure out how to store the error code data within our Clickhouse database
- Figure out how to display the information within the hive insights dashboard
- Breakdown of all error codes
- Breakdown of error codes per operation within the operation details view
Links
Background
We gather information about GraphQL requests that contain an error response (
errorskey is present within the GraphQL response).This information is used to display the success and failure rate of GeaphQL request within the Hive Console dashboard, insight view.
Total failure rate
Failure rate compared to success rate
Failure rate by operation
A common practice is to use the
codeproperty within the error extensions to identify the origin of the error.E.g. if a access token sent to a GraphQL API is expired, the following response could be interpreted by the frontend client for refreshing the access token.
{ "errors": [ { "message": "AccessToken expired", "extensions": { "code": "NEEDS_REFRESH" } } ] }Or if a request was made without an access token, the following response could be interpreted by the frontend client for showing a log-in form.
{ "errors": [ { "message": "AccessToken expired", "extensions": { "code": "UNAUTHENTICATED" } } ] }Apollo Server initially popularized this pattern and has become an unofficial standard for handling arbitrary errors that are not defined using the Schema SDL.
Task Overview
Users of Hive want to see the reason the reason on why the execution of a request failed without using additional tools. An enhancement would be to include the error code(s) within the usage reporting.
The following things need to be done:
Links
Original message:
Apollo Server error codes
Using error codes for doing authentication refresh on client
Hive usage reporting specification