RESTDataSource, cannot easily throw error if response is 200 #32
Comments
|
Can I see your solution for this, I am having a similar dilemma |
glasser
added a commit
that referenced
this issue
Dec 8, 2022
We previously removed `didReceiveResponse` which let you override the main "is it an error or not" logic. This restores it in an error-specific way. This means you can throw errors even on 200s if you want (or vice versa). This also changes the `errorFromResponse` hook to take options instead of a single argument, in case you want the error to reflect more data. One negative change is you can no longer prevent `parseBody` from being called, though you can always override `parseBody` to do less. Fixes #32.
glasser
added a commit
that referenced
this issue
Dec 9, 2022
We previously removed `didReceiveResponse` which let you override the main "is it an error or not" logic. This restores it in an error-specific way. This means you can throw errors even on 200s if you want (or vice versa). This also changes the `errorFromResponse` hook to take options instead of a single argument, in case you want the error to reflect more data. One negative change is you can no longer prevent `parseBody` from being called, though you can always override `parseBody` to do less. Fixes #32.
glasser
added a commit
that referenced
this issue
Dec 9, 2022
We previously removed `didReceiveResponse` which let you override the main "is it an error or not" logic. This restores it in an error-specific way. This means you can throw errors even on 200s if you want (or vice versa). This also changes the `errorFromResponse` hook to take options instead of a single argument, in case you want the error to reflect more data. One negative change is you can no longer prevent `parseBody` from being called, though you can always override `parseBody` to do less. Fixes #32.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Right now the
didReceiveResponseanderrorFromResponsepair works fairly well with non-2xx statuses. Unfortunately there exists REST services (legacy) which return 200 OK with error object instead as body. If trying to check this in didReceiveResponse and then throwing error through errorFromResponse causes problem with the response.json() parsing, as you cannot call that one twice.Either the
parseBodyshould know better (processing time memoize) orerrorFromResponseshould accept body passed and use that instead of callingparseBody. This would allow passing already parsed body to be passed tosuper.didReceiveResponse.Right now my solution is just to copy-paste (partially) code for of ApolloError object create from errorFromResponse to the custom didReceiveResponse.
The text was updated successfully, but these errors were encountered: