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] [Snippet] Unhandled exceptions are reported twice #2442

Open
VitaliyPotapov opened this issue Oct 31, 2024 · 3 comments
Open

[BUG] [Snippet] Unhandled exceptions are reported twice #2442

VitaliyPotapov opened this issue Oct 31, 2024 · 3 comments
Assignees
Labels
Milestone

Comments

@VitaliyPotapov
Copy link

Description/Screenshot
When using appInsights as a snippet, unhandled exceptions are reported twice.

Screenshot:
Image

Steps to Reproduce

  1. Open reproduction demo: https://7rslpk.csb.app/ ( https://codesandbox.io/p/sandbox/7rslpk )
  2. Open devtools network tab
  3. Wait for second request to /track and check the payload

Expected behavior
Only one unhandled exception is reported.

Additional context

@MSNev MSNev added the bug label Oct 31, 2024
@MSNev
Copy link
Collaborator

MSNev commented Oct 31, 2024

Ok, I've just tracked through your provided reproduction THANK YOU VERY MUCH, it was extremely helpful to identify this specific scenario.

The issue lies around in the changes that we have made for "populating" (and exposing) the dynamic config (so this bug has now been here for quite a while 😦 ) and how the snippet "informs" the main SDK that it has already "hooked" the window.onerror (so that it doesn't do it again)

As we have just released the final (planned) release for this year (because we are just entering the holiday lock down period) and we are limited in our ability to promote SDK versions to production unless they are required for high priority issues, lets start with a way for you to avoid this issue that I have identified.

Temporary Workaround

As a temporary work-around (until we can release a fixed version), you can add the following to the configuration that you pass to the snippet (SDK Loader)

        connectionString: " ... Removed ...",
        extensionConfig: {
          ApplicationInsightsAnalytics: {
            autoExceptionInstrumented: true
          }
        }

This will then populate the (internalish) flag that the snippet uses to inform the sdk that it has already hooked the onerror, into the location that the SDK is now looking at.

I'll add some more "fix" notes in a follow up comment as I have to run to a meeting right now.

@MSNev MSNev pinned this issue Oct 31, 2024
@MSNev MSNev added this to the 3.3.5 milestone Oct 31, 2024
@MSNev
Copy link
Collaborator

MSNev commented Oct 31, 2024

As part of fixing this the core SDK needs to either

  • add an additional check on the core config for the autoExceptionInstrumented on the following line, it should use both the core and _extConfig
    if (!_disableExceptionTracking && !_autoExceptionInstrumented && !_extConfig.autoExceptionInstrumented) {
  • or as an alternative we could add this key to the defaults so that the underlying config resolver handles picking this up from the root config, it may or may not require an additional fb definition (see the existing usage for the Cookie Cfg)
  • and/or update the next snippet to also populate the above "workaround" location, so that all SDK's releases (prior to fixing) will automatically resolve the issue.

Or a combination of the above, there may also be other alternative solutions that I have not yet identified.

@VitaliyPotapov
Copy link
Author

Thanks for the reply and the workaround.
I confirm it works!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants