apollo-link-error not able to ignore errors

Created on 31 Oct 2017  Â·  9Comments  Â·  Source: apollographql/apollo-link

Hello.
When I try to ignore errors with the error link by using response.errors = null I get this error message

Unhandled Rejection (TypeError): Cannot set property 'errors' of undefined
(anonymous function)
src/index.js:41
  38 | 
  39 | const errorLink = onError(({ response, operation, graphQLErrors, networkError }) => {
  40 |   if (operation.operationName === "signinUser") {
> 41 |     response.errors = null;
  42 |     return;
  43 |   }
  44 | 
View compiled
â–¼ 4 stack frames were expanded.
error
node_modules/apollo-link-error/lib/index.js:29
SubscriptionObserver.error
node_modules/zen-observable/zen-observable.js:174
SubscriptionObserver.error
node_modules/zen-observable/zen-observable.js:174
(anonymous function)
node_modules/apollo-link-http/lib/httpLink.js:130

    "apollo-link": "^1.0.0",
    "apollo-link-error": "^1.0.0",
    "apollo-link-http": "^1.0.0"
enhancement

Most helpful comment

I'm also experiencing this issue.

Except to test i'm causing the graphql server to not be online and it's hitting both the onError Handler and the .catch on the query.

I expect it to not error like that.

All 9 comments

@bogdansoare what type of error is being thrown? If it is a client side error (before the request is sent), there won't be a response to modify.

@jbaxleyiii it is thrown from the graphql backend, from a signin mutation when a user tries to sign in with the wrong credentials.

screen shot 2017-10-31 at 21 56 56

I have the exact same issue with my app. The signIn mutation should not throw an error when a 401 is returned.

I guess it is due to the fact, that we are trying do deal with a networkError which does not include a response object. See here: https://github.com/apollographql/apollo-link/blob/master/packages/apollo-link-error/src/index.ts#L29

But how are we supposed to ignore specific network errors?

Ok, now that I did a bit more research, my whole setup might be bad. GraphQL is transport layer agnostic and status codes are http specific. I guess we should return an error and ignore it the way it is documented. I will give that a try.

Hello there!

I have the same issue and now I use this workaround to suppress special errors:

import { ApolloLink, Observable as LinkObservable } from 'apollo-link';
...
        const suppress = new ApolloLink(
            (operation, forward) => {
                return new LinkObservable(observer => {
                    let sub;
                    sub = forward(operation).subscribe({
                        next: result => {observer.next(result);},
                        error: err => {
                            if (err.status == 401){
                                this.authService.handleInvalidToken();
                            } else {
                                observer.error(err);
                            }
                        },
                        complete: observer.complete.bind(observer),
                    });
                    return () => {
                        if (sub) sub.unsubscribe();
                    };
                });
            });

But it's just hacked version of: https://github.com/apollographql/apollo-link/blob/master/packages/apollo-link-error/src/index.ts#L24-L58
I really hope that it'll fixed soon, because now it's impossible to control error flow.

I'm also experiencing this issue.

Except to test i'm causing the graphql server to not be online and it's hitting both the onError Handler and the .catch on the query.

I expect it to not error like that.

I think this is still an issue? This also shows itself if you have a server that doesn't respond with a response object (as @namxam pointed out). Unless there's something I'm missing, it's not possible to catch that error anywhere, right? TypeError: Cannot read property 'data' of undefined

This is still a quite frustrating issue

Any update on this guys ?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

techyrajeev picture techyrajeev  Â·  3Comments

steffenmllr picture steffenmllr  Â·  4Comments

lobosan picture lobosan  Â·  3Comments

tim-soft picture tim-soft  Â·  4Comments

valerybugakov picture valerybugakov  Â·  5Comments