title: apollo-link-error description: Handle and inspect errors in your GraphQL network stack.
Use this link to do some custom logic when a GraphQL or network error happens:
;const link =;
Apollo Link is a system of modular components for GraphQL networking. Read the docs to learn how to use this link with libraries like Apollo Client and graphql-tools, or as a standalone client.
Error Link takes a function that is called in the event of an error. This function is called with an object containing the following keys:
operation: The Operation that errored
response: The result returned from lower down in the link chain
graphQLErrors: An array of errors from the GraphQL endpoint
networkError: Any error during the link execution or server response, that wasn't delivered as part of the
errorsfield in the GraphQL result
forward: A reference to the next link in the chain. Calling
return forward(operation)in the callback will retry the request, returning a new observable for the upstream link to subscribe to.
Observable<FetchResult> | void The error callback can optionally return an observable from calling
forward(operation) if it wants to retry the request. It should not return anything else.
An error is passed as a
networkError if a link further down the chain called the
error callback on the observable. In most cases,
graphQLErrors is the
errors field of the result from the last
networkError can contain additional fields, such as a GraphQL object in the case of a failing HTTP status code from
apollo-link-http. In this situation,
graphQLErrors is an alias for
networkError.result.errors if the property exists.
Retrying failed requests
An error handler might want to do more than just logging errors. You can check for a certain failure condition or error code, and retry the request if rectifying the error is possible. For example, when using some form of token based authentication, there is a need to handle re-authentication when the token expires. Here is an example of how to do this using
Here is a diagram of how the request flow looks like now:
One caveat is that the errors from the new response from retrying the request does not get passed into the error handler again. This helps to avoid being trapped in an endless request loop when you call forward() in your error handler.
If you want to conditionally ignore errors, you can set
response.errors = undefined; within the error handler: