Consider a GraphQL query that triggers an error with custom extensions. What will the error response contain?
{
"errors": [
{
"message": "User not found",
"extensions": {
"code": "USER_NOT_FOUND",
"timestamp": "2024-06-01T12:00:00Z"
}
}
]
}Custom error extensions appear inside the extensions field in the error object.
The GraphQL error response includes a list of errors. Each error can have an extensions field that holds custom data like error codes and timestamps.
In GraphQL, where do you put extra information like error codes or debug data in an error response?
Think about where extra metadata about errors is stored.
The extensions field is designed to hold custom error information beyond the basic message.
Which of the following GraphQL error objects has an invalid extensions field format?
The extensions field must be an object, not a string.
Option A uses a string for extensions, which is invalid. It must be an object with key-value pairs.
A server returns this error object but the client does not see the extensions field. What is the likely cause?
{
"errors": [
{
"message": "Access denied",
"extensions": null
}
]
}Check the type of the extensions field.
The extensions field must be an object with key-value pairs. Null disables the extensions data.
You want to send multiple errors with custom codes in a GraphQL response. Which approach is best for performance and clarity?
Think about how GraphQL error objects are structured.
Each error should have its own extensions object with a code field. This keeps errors clear and easy to handle.