Improve Apollo 4 error capturing
Closed this issue · 3 comments
Description
The Apollo 4 migration guide mentions that "fetch errors like network errors, cache misses, and parsing errors [...] are now surfaced by returning (for execute()) or emitting (for Flows) an ApolloResponse with a non-null exception instead of throwing it".
We are currently using the same logic for Apollo 4 as for Apollo 3.
We should investigate in which specific cases this field is set and if the SDK is behaving correctly in those cases (sending an error or a warning/error level breadcrumb).
After some preliminary tests, it seems that the logic for Apollo 3, without special handling for the new exception field, leads to the same behaviour of the SDK for Apollo 4 as for Apollo 3, as in both cases we can tell if an operation failed by the presence of the errors field in the response body or by looking at the HTTP response code.
Let's not forget to update our docs for Apollo 4 support.
After some preliminary tests, it seems that the logic for Apollo 3, without special handling for the new exception field, leads to the same behaviour of the SDK for Apollo 4 as for Apollo 3, as in both cases we can tell if an operation failed by the presence of the errors field in the response body or by looking at the HTTP response code.
Let's close this then and reopen in case something comes up where we actually notice different behaviour and then address in that case.