Your data. Anywhere you go.

New Relic for iOS or Android


Download on the App Store    Android App on Google play


New Relic Insights App for iOS


Download on the App Store


Learn more

Close icon

Ajax calls report network error 90% of the time


#1

https://rpm.newrelic.com/accounts/1090643/browser/18123125/bjax_requests

We use the copy/paste SPA agent

Since the 21st of January 90% of ajax calls are reported as “Network error”. The response status 0 is also shown is session traces. However, this does not reflect reality. We cannot reproduce the problem and no errors are reported. The agent does not seem to be able to retrieve the status from the response.

Any idea of what may cause this?

On a side note: when selecting one of the end point there seems to be a bug with the status code percentages
image


#2

Hi @reqtest,

Interesting - thanks for the alert. I’m not sure yet what might be happening but we’ll look into it and let you know when we have more information.


#4

Hi @reqtest,

We’ve done some research into this, and one of our engineers was able to reproduce the behavior on your application.

It looks the Angular http client is causing problems for same-origin requests. Our agent thinks that the XHR request didn’t finish because the readyState of the XHR request is never set to 4 (done). If the XHR request isn’t finished (defined as the readyState being set to 4) by the time XHR/error harvesting happens, our agent sets the http status of the XHR request to 0.

The Angular http client seems to be taking control of XMLHttpRequest functionality. Our engineer checked xhr.readyState for the XHR requests that have status set to 0 and discovered that xhr.readyState was undefined and other functions in the XHR object were being wrapped by Angular’s http client.

We found two versions of the Angular http client in their documentation, the newer one and the older one. The newer one (common/http) does not have xhr.readyState, which our agent relies on to evaluate whether an XHR request was finished. The older one client (http) does have xhr.readyState.

If you’d be willing to confirm which version of Angular and the HTTP client you’re currently using, we’d really appreciate you sharing that, both for our documentation and for other customers who might be experiencing the same issue.

We’ll be looking into this to determine whether changes to our agent will be needed. In the meantime, we suggest trying the older version of the Angular http client (if you’re currently using the newer version), switching to fetch(), or even not using the Angular http client at all, depending on your use case.


#5

Good to hear we are getting to the cause of the problem.

Angular CLI: 1.7.0
Node: 8.12.0
OS: win32 x64
Angular: 4.4.6
… animations, common, compiler, compiler-cli, core, forms
… http, language-service, platform-browser
… platform-browser-dynamic, router, tsc-wrapped

@angular/cli: 1.7.0
@angular-devkit/build-optimizer: 0.3.1
@angular-devkit/core: 0.3.2
@angular-devkit/schematics: 0.3.1
@ngtools/json-schema: 1.2.0
@ngtools/webpack: 1.10.0
@schematics/angular: 0.3.1
@schematics/package-update: 0.3.1
typescript: 2.3.4
webpack-dev-server: 2.11.1
webpack: 3.11.0


#6

Hey there @reqtest - just popping in to say that this is still being investigated. In the meantime, we were wondering if you had tried the older Angular http client. That would give us another clue to work from. Thanks!


#7

I’m not sure that the version of the http client is the cause, since it worked fine before the 21st of January. Is there any update you have done to the browser client around that time? There were no changes on our end that could have caused this.

We can try with an older http client, please suggest a version.


#8

Hi @reqtest,

I’m going to open a ticket for you, we can update this post once we get a solution. Keep an eye out for an email from our ticketing system.


#9

Hello, any update in this issue?.. I am facing the exact same problem


#10

Hi @angel.soteldo,

It’s an issue with Angular, and we’ve got an ongoing investigation. I’m going to go ahead and open a ticket for you.