Exception in nrWrapper


Interesting! The lite agent does have fewer features, and no error or AJAX reporting, so if the underlying issue is a conflict between Cypress and our products with regards to XMLHttpRequest that could be why switching to the lite agent addressed it. I’ll see if we have any records of other issues in this area.

Either way, for @jblumenfeld it would still be well worth addressing the installation issue as that’s a frequent cause of agent errors.

Hi Guillaume,
My solution right now is to have cypress listen for exceptions and ignore it if it looks like the same exception. Something like:

Cypress.on('uncaught:exception', (err) => {
    // returning false here prevents Cypress from
    // failing the test
    if (err.message &&
       err.message.startsWith('Cannot set property \'status\' of undefined')) {
      return false;
    return true;

@jblumenfeld - Thanks for sharing your solution here :smiley:

We ran this by the Browser engineering team and they took a look. I’ll quote from their findings here:

Cypress.io patches XMLHttpRequest, similarly to the NR agent. However, it modifies the prototype chain, so that the open and send methods cannot be instrumented by us. This has a side-effect of the agent causing an error when tests are run in Cypress. This should not affect production apps, but it will affect customers who are running tests with the NR agent present in their code.

We’ll be adding something on this to our Browser documentation.


Hey there,

We are getting this in our production application at Procore and we are not sure why this keeps reporting so many bugsnag errors.

I am trying to debug the injected script, but I am getting no results understanding the situation.

Why would params be undefined?

t.params.status = e.status;

An example of params

host: "sessions.bugsnag.com:443"
method: "POST"
pathname: "/"

So it seems to be all the configuration of the XHR request.

I looked for .params and I didn’t see any reset to undefined value, or at lest no direct.

Could you help to fix this issue please, currently is reporting 100K errors per day, also it seems to happen in particular cases.

Is this somehow related to a malformed request or something?

Please help.

Hello Yordis,

I’ve been looking through some previous tickets from customers who’ve reported similar errors when using Browser and Bugsnag together. Our research in the past points to this being a conflict between the two tools (as sometimes happen) but I’ve not been able to find any cases yet with a documented resolution. Our agent is reporting something similar in your application as well:

I also dug around in Insights and found some error events with at least some trace data:

Are you able to reproduce this at all in the live application? I tried to check myself but couldn’t access it.



We are having this error also. The error is intermittent. I cannot reproduce it myself.

We use Rollbar for error reporting. Can NR conflict with Rollbar?

Hi @aleksandr2,

Unfortunately, I’m not finding much information about Browser and Rollbar not working together in our ticket history. Have you tested this with using the Lite version of the Browser agent or removing Rollbar to see if the errors still occur?

Hello @imattice!

Thank you for response!
We cannot remove Rollbar. It is our main error logging tool.

I will investigate Lite version. What else can cause this error if not Rollbar?

Hey there,

I am sorry I didn’t have the time to respond.

I will be disabling Bugsnag and see how it goes to validate that the integration is the problem today.

Which it actually could make sense, Bugsnag as NewRelic tries to hack all the XHR requests and try to subscribe to global error handling so your tools may conflict with each other.

Let me see how far I can get into this.

It would be really helpful to have an uncompiled version of NewRelic Browser so I can debug easier, so please share it if you can.

Hey @yordis.prieto - Thanks for testing with Bugsnag disabled.

Right now I don’t believe we have a uncompiled version of the browser agent that we can share. But I’ll make sure that the right team knows that there is interest in having that.

Let us know how your test goes.

@RyanVeitch thank you very much for the update,


We disabled Bugsnag wasn’t the issue, and other tools that we thought were causing the issues but it seems that it is not Bugsnag nor the other tool we tested.

It seems to be a particular computer cause all the issues so at this point we are trying to contact the person who owns the computer to understand why this is happening since it is that particular person only (at least from our findings).

Thanks for that info @yordis.prieto I’m curious what you learn from working with that one user. - be sure to let us know :smiley:

Didn’t happen :sob: we had to ignore the error for now.

1 Like

That’s a shame! Well let us know if we can help further, or if you can end up tracking this down at some point.

@yordis.prieto Could you share how you ignore that error?
We’re getting same error after updating NR script. But couldn’t reproduce ourself.
As you said, it seems very few particular user reporting a lot of error, so I guess that they’re reported infinite looped. And I’d prevent that repetition at least.


If you want the Browser agent to ignore the errors, you can use setErrorHandler(). Also, in case it got lost from earlier in the thread, after that first report we established that this an issue with us and Cypress when running tests with the Browser agent present in the code but it shouldn’t affect production. We added that to our docs here:: https://docs.newrelic.com/docs/browser/new-relic-browser/getting-started/compatibility-requirements-new-relic-browser#frameworks

An update to Cypress brought me here only to find I already implemented @jblumenfeld 's solution.
This was fine in 4.5
In 4.8 the errors come back prefixed with “The following error originated from your application code, not from Cypress.”

Changing this to an includes updates the patch :wink:


Thanks for the heads up @Philip.Jory - I’ll pass that on to our team. We’re also planning to adjust the agent in the near future so that it plays better with Cypress from the get to but until we can make that available this is helpful information.