3

I have a React frontend that's hooked up to Sentry, and I've gotten quite a few reports in the past few weeks, completely randomly (different users and different devices) with the following error:

Error: Network Error
  at createError(../node_modules/axios/lib/core/createError.js:17:15)
  at apply(../node_modules/axios/lib/adapters/xhr.js:80:14)
  at XMLHttpRequest.r(../node_modules/@sentry/browser/esm/helpers.js:87:17)

Axios code it's referencing in the stack trace:

request.onerror = function handleError() {
  // Real errors are hidden from us by the browser
  // onerror should only fire if it's a network error
  reject(createError('Network Error', config, null, request)); // Clean up request
  request = null;
}; // Handle timeout

I don't believe this has anything to do with Axios specifically as this indicates that the onerror event handler is being triggered on the request, which is part of XMLHTTPRequest.

What's even stranger is that oftentimes I see a successful API request go through moments before from the same user, and then it fails with this error and then works again after a few seconds when the user (presumably) refreshes. When I check the logs for the backend (written in Node) I find that about half the time, I actually see the request getting logged and going through, and the other half of the time, there's no indication that the request at the timestamp of the error ever occurred. So this leads me to infer that sometimes, when Network Error gets thrown, the request never reaches my server, and sometimes, even when a successful response is sent back rom my server, somehow it gets lost in transmission? I know it has to do with an error occurring lower than the application layer, so an HTTP 500 wouldn't cause this to fire.

I don't understand how this can happen though. Shouldn't TCP retransmission cause a retry to happen if there's a lost packet? It's not just a one-off error, it's happened 20+ times over the past few weeks.

Some notes:

  • Some research led me to thinking it had to do with the CORS preflight. The following headers are set in the response:
    'Access-Control-Allow-Origin': '*'
    'Access-Control-Allow-Headers': 'X-Requested-With'
  • Keep alive is set to true on the backend.

  • Server is running on Heroku

  • Clients are on multiple different networks on multiple different devices

Any thoughts on a) why this could happen only seconds after a successful request went through and b) ways to pin down the origin? Or is this just a completely normal, ephemeral error that could commonly occur?

rb612
  • 5,280
  • 3
  • 30
  • 68

1 Answers1

0

A response of 500 won't cause a Network Error by itself. There are a few reasons one can occur. It seems that XHR returns the error without much detail or information for why, so it's on browsers to make these errors better.

Often when you see a Network Error it will be accompanied by a status code of 0, which means it likely never reached the server, or the api is not returning correctly under every instance.

If it is a 0 status, then it could be any of this Does an HTTP Status code of 0 have any meaning?

Some causes for this error include, but is not limited to:

  • When a response has no body
  • If a request is blocked by browser extensions
  • A CORS event failing
  • Some browsers like safari being more strict about cross origin requests
  • Received a connection refused error

Hopefully this helps narrow things down