404 OK Response is returning null instead of an error

[kevinrobayna]

Recently I was working in a project using apollo-link-rest to make homogeneous the different calls (to different endpoints) that the app was using. Some endpoints are GraphQL some others rest.

One of my endpoints was failing as the resource i was looking for did not exist and therefore the fetch was returning a 404. But since #119 & #142 (https://github.com/apollographql/apollo-link-rest/blob/master/src/restLink.ts#L1047).

Why would make sense to hide information from the response? Could this be done in a configuration based?

[fbartho]

For many companies, a 404 is a "non-fatal error" -- it just means something is absent. There's often no "extra" data in the 404 response, so returning null seemed like the model that best fit GraphQL. Based on discussions in #119 and outside, it seemed like there was consensus that this was defaulting to a more painful outcome, so the change was made.

If you still want to cause this to fail, you can write your own customFetch wrapper that will throw an Error when 404 occurs.

[kevinrobayna]

Thanks @fbartho I think that makes sense. I think the issue in our case is that out schema looks very REST-y so that makes it difficult to work without the 404. I'll go ahead and implement my own customFetch. Thanks!

[manuelmhtr]

I don't think 404 errors should be treated differently, they still a client error.

[anasnain]

@kevinrobayna were you able to handle 404 error? I have a similar requirement. I need to handle a 404 error. Currently, the apollo client is returning null data. while I see it's 404 in network inspector.

[manuelmhtr]

@anasnain I had to handle it in the onCompleted event:

onCompleted: (data) => {
  const token = data?.passwordRecoveryToken;
  // Apollo client sends null on 404 errors: https://github.com/apollographql/apollo-link-rest/issues/119
  if (!token) return handleEmailNotFound();

  return onGoToVerifyCode({ tokenId: token.id, email: inputs?.email?.value });
},

[christrude]

I have put up a PR to reinstate 404's as normal network errors, to coincide with good REST API practices: #283