error link does not give a real error object, thus no networkError.statusCode access possible

[miracle2k]

I am basically using this example from the docs ("Afterware"): https://www.apollographql.com/docs/react/basics/network-layer.html

import ApolloClient from 'apollo-client';
import { HttpLink } from 'apollo-link-http';
import { onError } from 'apollo-link-error'
import { logout } from './logout';
const httpLink = new HttpLink({ uri: '/graphql' });
const logoutLink = onError(({ networkError }) => {
  if (networkError.statusCode === 401) logout();
})
const client = new ApolloClient({
  link: logoutLink.concat(httpLink),
});

This doesn't work for me. "networkError" seems to be raised as a string, and only tells me "Failed to fetch". It doesn't have a stack, nor the .statusCode property.

https://www.webpackbin.com/bins/-KyLJ0NyjpkxU0ggok70

[maurodelazeri]

+1

the way I'm solving this temporarily is by picking up the status directly on the component that makes the call

componentWillReceiveProps(nextProps) {
console.log(
"life cycle: componentWillReceiveProps",
nextProps.data.networkStatus
);
}

ex:
7 = 200
8 = 401

[leethree]

Yes, the networkError object is not very helpful and the response object is missing. There's no way to handle HTTP status codes in network layer.

[tjpeden]

This is kind of a big deal, I haven't found a solution for angular

[jbaxleyiii]

@miracle2k we are working to improve errors with #244, does it look like it will fix your issue?

[miracle2k]

@jbaxleyiii Not sure, but a quick scan of the patch set doesn't lead me to conclude that it changes the object that networkError is; if you look at the webpackbin link I put above, this seems to be a string, which means we don't know the status code.

Specifically, I want the status code so I can handle "403 Not Authorized" responses from the server and redirect to a login screen. This seems impossible right now.

[tjpeden]

@miracle2k Looks like they added test coverage around 401 (which is what I think you mean) so hopefully that means the things they changed actually produce a result containing the status code.

I would like to point out, however, that your webpackbin demonstrates (for me at least) that networkError.statusCode is undefined, not a string. That behavior is consistent with my findings as well though. I have hope that this patch fixes that issue.

[yuricamara]

The problem and the solution (I guess)

export interface ErrorResponse {
  graphQLErrors?: GraphQLError[];
  networkError?: Error;
  response?: ExecutionResult;
  operation: Operation;
}

from

apollo-link/packages/apollo-link-error/src/index.ts

Line 4 in 98eeb1d

export interface ErrorResponse {

Error in "networkError?: Error" should be like HttpErrorResponse from Angular

A workaround

With Angular

   import { HttpErrorResponse } from '@angular/common/http';	

    const errorLink = onError(({ networkError }) => {
      const networkErrorRef:HttpErrorResponse = networkError as HttpErrorResponse;
      if (networkErrorRef && networkErrorRef.status === 401) {
        console.log('Going to login page...');
      }
    });

Without Angular

Create the type HttpErrorResponse like the one from Angular or change it for 'any'

const errorLink = onError(({ networkError }) => {
  const networkErrorRef:HttpErrorResponse = networkError as HttpErrorResponse;
  if (networkErrorRef && networkErrorRef.status === 401) {
    console.log('Going to login page...');
  }
}); 

[jbaxleyiii]

This should be fixed in the newest release thanks to @evans work!

[goldenbearkin]

seems it hasn't fixed.

[miracle2k]

Same here. I updated the webpackbin above with the latest releases to show that the statusCode is still not accessible.

[webmobiles]

yes, please waiting the fix, I've upgraded but have this problem in the real production environment..

[bogdansoare]

Also having this issue.

[akrigline]

Likewise. @jbaxleyiii It doesn't look like the latest npm releases have this in.

[webmobiles]

apollo looks a project abandoned, i'm migrating to manual fetch with javscript

[evans]

@webmobiles I'm sorry you feel this way! I hope that we can work together to fix this now

Let's move the conversation to the open issue #300