Disable console breadcrumbs in dev environments

[joshuap]

Honeybadger's console instrumentation (for breadcrumbs) hijacks the stack trace in console logs, which is annoying in local development. Should we disable that instrumentation for dev environments by default?

[mohitharshan123]

@joshuap Is there any way to disable honeybadger reporting errors when user manually runs js from console ? Users might be just using the console to test something totally unrelated and it would create unnecessary issues in the repo.

[joshuap]

@mohitharshan123 I don't know of a way to selectively disable our instrumentation if the code is in the console, but we shouldn't be reporting uncaught errors in the console. Calling Honeybadger.notify directly may report errors, as would calling some other async functions such as setTimeout. Do you know how the unwanted errors are being reported? Take a look at our Reducing Noise guide—you may be able to ignore the errors based on some other common factor.

[subzero10]

@joshuap Is there any action we want take from this?

Should we go ahead and implement the original idea disable instrumentation for non-prod environments by default (it has 5 upvotes at the time writing this message)?

[joshuap]

@joshuap Is there any action we want take from this?

Should we go ahead and implement the original idea disable instrumentation for non-prod environments by default (it has 5 upvotes at the time writing this message)?

This might be the way to go. The reason that instrumentation is not disabled in development environments currently (and this is how most of our other libs work) is that I want to run as much production code as I can so that bugs or incompatibilities surface earlier (and in test runs). That's why "dev environment" usually just means that we don't send live data, but everything else works like it will in production. Does that make sense?

The main problem here is how console logging works in the browser, and hijacking it unfortunately removes useful debug info. So at the very least, maybe we shouldn't be doing that in dev mode.

What do you think?

[subzero10]

That's why "dev environment" usually just means that we don't send live data, but everything else works like it will in production.

FYI, I'm totally onboard with this.

The main problem here is how console logging works in the browser, and hijacking it unfortunately removes useful debug info. So at the very least, maybe we shouldn't be doing that in dev mode.

Can you share an example of removed debug info so that I can do some research/testing on my side? I'm trying to reproduce by logging an error in the console with and without Honeybadger and I don't see the difference. Note: This reminds me of the vue.js console logging inconsistencies we had to deal as well.

[joshuap]

@subzero10 as far as I remember, the issue was that with console breadcrumbs enabled, anything logged to the console would show "honeybadger.js" instead of the real location that called console.log. Is that not the case anymore? You might try a few browsers—I think I'd reproduced this at least in Chrome.

[subzero10]

Oh, now I see. I remember stumbling on this at some point in the past. OK, I will check!

[subzero10]

Could this be solved with the Framework Ignore List of Chrome? Other browsers have similar features as well. I was going through Sentry docs and stumbled upon this 😃

[barnabaskecskes]

That ignore list has disappeared from Brave (and from Chrome as well). Any ideas how to get around this issue? I thought of not loading Honeybadger in local development, but I'm not a fan of "if not in production" type of conditionals either...

[joshuap]

That ignore list has disappeared from Brave (and from Chrome as well). Any ideas how to get around this issue? I thought of not loading Honeybadger in local development, but I'm not a fan of "if not in production" type of conditionals either...

You should be able to selectively disable the console breadcrumbs option in development:

https://docs.honeybadger.io/lib/javascript/guides/breadcrumbs/#enabling-disabling-breadcrumbs

Here's what I do:

// Assuming you have a `HONEYBADGER_ENVIRONMENT` constant (I inject this in my webpack/esbuild configs)
const isDev = HONEYBADGER_ENVIRONMENT !== 'production'

Honeybadger.configure({
  breadcrumbsEnabled: {
    dom: true,
    network: true,
    navigation: true,
    console: !isDev 
  }
})

// or (to disable all breadcrumbs):

Honeybadger.configure({
  breadcrumbsEnabled: !isDev
})

[barnabaskecskes]

Thanks, @joshuap - however, sadly, that did not help me achieve what I wanted. (Making me wonder whether I'm on the right thread at all! 😅)

Just to clarify, my issue is that when I encounter an error in the dev environment, Honeybadger gives me a log stating what would have been sent to the cloud if it wasn't a local env (with an unusable stack trace), and past that the actual error in the console is pointing to honeybadger.js instead of the real location of the issue.

If I turn Honeybadger off for the local environment, it gives me a usable link to the actual problem in the code.

I can use this solution if it's a must, but I would be more comfortable should I be able to control this with a setting of Honeybadger rather than making dev work differently than production if that's all possible?

[subzero10]

Hey @barnabaskecskes, the issue you are facing is very similar to this issue/thread, yet not exactly the same. Your screenshot made me realize that you are using the @honeybadger-io/vue package, right?

@joshuap's recommendation should have solved your issue if you were using the base library @honeybadger-io/js and not leveraging Honeybadger's Vue.js package. The idea here, as this page describes, is that Honeybadger creates a wrapper method for all console methods in order to capture logs and enrich events that are reported to Honeybadger so that you can better debug errors. This is what the breadcrumbs plugin does, and if you are not familiar with it here's the documentation page.

Disabling breadcrumbs for console log should stop Honeybadger from overriding the console methods and therefore you should get the right stack regardless if Honeybadger is enabled or not.

However, for the vue.js package, there is an additional piece of information:

• In order to automatically capture errors that are related to the Vue.js framework and provide richer context, we have to attach an errorHandler on the vue app (ref: app.config.errorHandler)
• With this, there is no way for us to reconstruct the default error message that is logged from the Vue.js framework. For vue.js v2, we were able to actually replicate the exact error message by copying and re-using the original code to Honeybadger's vue.js package. For vue.js v3, this became a lot more complex and not simple to replicate because the logic that produces the default error message spans multiple files that are not exported (at least last time I checked).
• To sum up, I think the issue you are facing here is not that the logged message appears to be from honeybadger.js, but the fact that you are getting a different error message (with less information and a poorer context) when Honeybadger is enabled.

Unfortunately, I do not have a good workaround to suggest a fix for your issue, other than disabling Honeybadger entirely locally:

if (!isDev) {
  app.use(HoneybadgerVue, config)
}

From my side, I plan to have another look on constructing a better error message and see if things have changed since we last worked on this.

[barnabaskecskes]

@subzero10 thank you for the detailed explanation, I do appreciate your help! For now, I'll resort to disabling Honeybadger for the local environment similarly as suggested - it works well that way, I just thought I must doing something wrong...! Thank you!