-
Notifications
You must be signed in to change notification settings - Fork 2.7k
Description
In Apollo Client v4, the type of error that can be received in ErrorLink changes depending on the Content-Type of the server response.
- GraphQL over HTTP spec compatibility
- https://www.apollographql.com/docs/react/migrating/apollo-client-4-migration#graphql-over-http-spec-compatibility
The default Accept header is now application/graphql-response+json,application/json;q=0.9 for all outgoing requests
The application/graphql-response+json media type is now supported and the client handles the response according to the application/graphql-response+json behavior
The application/json media type behaves according to the application/json behavior
The client now does the following when application/json media type is returned.The client will throw a ServerError when the server encodes a content-type using application/json and returns a non-200 status code
The client will now throw a ServerError when the server encodes using any other content-type and returns a non-200 status code
This behavior is introduced in following PR:
- Add more strict compatibility with GraphQL over HTTP spec #12644
- "GraphQLErrors" field will often not populate, errors instead stuck in "NetworkError" #9870
Due to this change, what could be received as GraphQL Errors up to Apollo Client v3 can now only be received as ServerError.
With ServerError, detailed GraphQL Error information is no longer included in error.extensions, making error handling difficult.
In cases where the backend server is not under management (for example, when using 3rd party API like GitHub API), if the server does not strictly comply with the GraphQL Over HTTP specification, error handling in Apollo Client v4 becomes difficult, preventing the upgrade to Apollo Client v4.
Specifically, error.extensions can no longer be obtained in ErrorLink, making it impossible to implement error retry logic and similar functionality.
Is there a way to relax this strict specification compliance?
Or are there any workarounds?
Simply put, I just need to be able to extract error.extensions from ServerError.