Report connectors errors as fetch errors #5829
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
With connectors, the subgraph service and connector service are called from a fetch service. This created some differences in how errors from the subgraph service were being reported through the fetch service compared to when the subgraph service was called directly. These differences have been removed, so errors from the subgraph service, or errors when invoking the subgraph service, will be reported exactly as before - always as
FetchError::SubrequestHttpError
.Additionally, HTTP errors from a connector REST API call are now also reported as
FetchError::SubrequestHttpError
, with the connector information in theservice
extension.FetchError::SubrequestHttpError
is consistently converted to a GraphQL error throughto_graphql_error
.The
connectors::Error::RequestLimitExceeded
error from the connector service now also has ato_graphql_error
function, and is reported out slightly differently since it is not an HTTP error (connectors will not make the HTTP request at all once the request limit is exceeded). The connector information is now included in theservice
extension in this case for consistency with the HTTP errors.Checklist
Complete the checklist (and note appropriate exceptions) before the PR is marked ready-for-review.
Exceptions
Notes
Footnotes
It may be appropriate to bring upcoming changes to the attention of other (impacted) groups. Please endeavour to do this before seeking PR approval. The mechanism for doing this will vary considerably, so use your judgement as to how and when to do this. ↩
Configuration is an important part of many changes. Where applicable please try to document configuration examples. ↩
Tick whichever testing boxes are applicable. If you are adding Manual Tests, please document the manual testing (extensively) in the Exceptions. ↩