raygun4js icon indicating copy to clipboard operation
raygun4js copied to clipboard

raygun4js hijacking console.log stack trace in developer tools, even when not enabled.

Open JLongley opened this issue 5 years ago • 9 comments

We use raygun for error logging in production, but want to have it disabled in development mode. After importing the module into our react project, it makes debugging locally with console.log quite difficult because it overwrites the stack trace of the original message with one that just points down into the internals of the module.

e.g.:

    console.log('Before importing raygun')
    import('raygun4js').then(module => {
        console.log('After importing raygun')
    })

In the console:

Before importing raygun     index.js:40
After importing raygun      raygun.umd.js:1774

Is there any way to disable this behavior?

JLongley avatar Feb 13 '20 01:02 JLongley

Thanks for raising the issue @JLongley. Sadly there isn't a way to currently disable this behaviour.

We can look at fix this behaviour in a future release but I can't give a estimate as to when that would be :)

BenjaminHarding avatar Feb 16 '20 21:02 BenjaminHarding

I found a temporary solution. You can add raygun.umd.js script to chrome dev tools blackbox, so any logs to console will ignore raygun wrapper.

Screen Shot 2020-02-17 at 19 10 14

criticalserenity avatar Feb 17 '20 16:02 criticalserenity

We have recently upgraded our Raygun dependency from "2.2.5" to "2.25.1" and discovered the same issue. In our case it is causing delays of up to 40 seconds in our development environment. @BenjaminHarding can you please provide an update on the status of this issue. Can you also please provide suggested JS code to workaround this in the meantime. i.e. what is the recommended way to revert default behavior

In the meantime we have tested various version and decided to stay on 2.5.3 which does not have the console.log hijack

hipitihop avatar Apr 26 '22 05:04 hipitihop

Hi @hipitihop - Ben Harding isn't with Raygun these days, but I'll bring in one of the team to pick this up!

CmdrKeen avatar Apr 26 '22 21:04 CmdrKeen

@CmdrKeen Thanks. I like to also note that this console hijack also tends to obfuscate the devtools/console log source. It links to this hijack, instead of the true source generating the log entry.

hipitihop avatar Apr 27 '22 00:04 hipitihop

Hi @hipitihop,

The console wrapper can be disabled by calling rg4js('disableAutoBreadcrumbsConsole'), which will restore the unwrapped console functions.

In our case it is causing delays of up to 40 seconds in our development environment.

This is concerning, and definitely shouldn't be occurring. I'd be interested to know if still happens when using disableAutoBreadcrumbsConsole, since that might be another issue entirely.

Widdershin avatar Apr 27 '22 03:04 Widdershin

@Widdershin Thanks for the prompt response. With 2.25.3 that fn disableAutoBreadcrumbsConsole is not available. I tried disableAutoBreadcrumbs instead. Indeed this seems to have removed the wrapper and sorted our performance issue. The Tracking XHR wrapper seems to remain, but we are not aware of any issues with this at this point. Let me know if you need more details.

hipitihop avatar Apr 27 '22 06:04 hipitihop

@hipitihop glad that sorted it out. We're planning to disable console breadcrumbs by default in a future release.

I'll open a separate issue to track that performance problem, definitely sounds like something we should get to the bottom of. What sort of delays did you experience? Full page freezes or delays in sending exceptions?

I think the XHR wrapper not disabling is a known issue, but I'll try to get that resolved for the next release in any case.

Widdershin avatar Apr 28 '22 06:04 Widdershin

@Widdershin

  1. The performance issue: For developers (not production builds), we use re-frame-10x. When the console.log is hijacked by Raygun4JS, we would experience delays of up to 40 seconds in this tool. In turn, this would also effect our main apps-ui rendering. We did not notice delays related to sending exceptions.
  2. As for the XHR wrapper not disabling, as mentioned, this alone does not cause any issues at our end at this point. However, perhaps both the console and the XHR should be independently controllable, perhaps even via your options arg.

hipitihop avatar Apr 29 '22 07:04 hipitihop