Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[BUG] Unhandled errors not logged #2013

Closed
maxburs opened this issue Mar 9, 2023 · 5 comments
Closed

[BUG] Unhandled errors not logged #2013

maxburs opened this issue Mar 9, 2023 · 5 comments

Comments

@maxburs
Copy link

maxburs commented Mar 9, 2023

Description/Screenshot
Unhandled exceptions are not logged in our app.

Steps to Reproduce

  • OS/Browser: Chrome/Macos
  • SDK Version [e.g. 22]: Repros on 2.7.3 and 2.8.11
  • How you initialized the SDK:
import { ApplicationInsights } from '@microsoft/applicationinsights-web';

// Inside init function
const appInsights = new ApplicationInsights({
    config: {
        enableDebug: true,
        enableDebugExceptions: true,
    },
});

appInsights.loadAppInsights();
appInsights.context.application.ver = KWE_CONSTANTS.env.appVersion;
appInsights.context.session.id = sessionId;

Expected behavior

Additional context
Add any other context about the problem here.

I saw some references to the "unhandledrejection" event in node_modules/@microsoft/applicationinsights-web/browser, but don't see that event listener on our window:
image

@MSNev
Copy link
Collaborator

MSNev commented Mar 9, 2023

Application Insights hooks and uses the window.onerror to capture the unhandled exceptions, and it's not registered as an event (via addEventListener etc)

So if you are using a framework that is also wrapping the onerror then depending how it's handling that and whether it passes it only any previous onerror handler will determine if they are captured.

This will require some debugging to check whether the onerror is being hooked and called.
This all occurs here

if (!_disableExceptionTracking && !_autoExceptionInstrumented && !extConfig.autoExceptionInstrumented) {
// We want to enable exception auto collection and it has not been done so yet
_addHook(InstrumentEvent(_window, "onerror", {
ns: _evtNamespace,
rsp: (callDetails: IInstrumentCallDetails, message, url, lineNumber, columnNumber, error) => {
if (!_disableExceptionTracking && callDetails.rslt !== true) {
_self._onerror(Exception.CreateAutoException(
message,
url,
lineNumber,
columnNumber,
error,
callDetails.evt
));
}
}
}, false));
, so putting a breakpoint on line 705 will confirm that your configuration is allowing exceptions to be gathered (which it does by default) and then when an exception occurs the rsp callback function on lines 708..717 will get called.

On you config items above, these are actually not for "unhandled errors", they are used to help track down issues which internally call the throwInternal messages which indicate that the SDK is not configured correctly etc.

if (_enableDebugExceptions) {
throw dumpObj(message);
} else {

Actually, digging into the code the enableDebug looks like a left over config from v1 as it was replaced by enableDebugExceptions

@maxburs
Copy link
Author

maxburs commented Mar 14, 2023

@MSNev

I checked and window.onerror is from AppInsights.

window.onerror is not called in all of the cases the "unhandledrejection" event is fired. I need logging for these events as well. This includes unhandled exceptions, which window.onerror doesn't track.

It looks like you have support for tracking this event here:

_addHook(InstrumentEvent(_window, "onunhandledrejection", {

Any idea why this isn't getting run?

@MSNev
Copy link
Collaborator

MSNev commented Mar 14, 2023

Yep, we have an additional configuration for that enableUnhandledPromiseRejectionTracking (which is off by default for backward compatibility). Enabling that this code you linked which attaches itself to the window.onunhandledrejection event.

@maxburs
Copy link
Author

maxburs commented Mar 23, 2023

@MSNev That fixed it! Sorry for opening this issue when it was a config problem. I did try searching through the docs and googling before opening this, but didn't look at your docs closely enough.

Do you know why this flag is off my default? Does enabling have some downside I should be aware of?

@maxburs maxburs closed this as completed Mar 23, 2023
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Mar 23, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants