CHECKOUT-6524: Fix Sentry client initialization to avoid conflict

[davidchin]

What?

• Create our own BrowserClient and Hub to avoid conflicting with the global BrowserClient and Hub provided by Sentry Browser SDK.
• Relax the error filtering rule to report errors as long as some of the frames in the stack trace are thrown from the app code.

Why?

• Some of our merchants also use Sentry and want to log front-end errors against their account. We want to ensure that our Sentry client doesn't interfere with theirs. Otherwise, errors will only get logged against one of the accounts, depending on their initialisation order. The way to solve this problem is by creating a separate client instance and using it directly. See https://docs.sentry.io/platforms/javascript/troubleshooting/#using-a-client-directly).
• Not all error frames come from the application code. For example, some are native code so they don't have a filename. Currently, if one of the error frames in the stack trace doesn't have a filename or a filename that doesn't match with the asset host, the error doesn't get reported. To fix this issue, we need to relax the filtering rule.

Testing / Proof

@bigcommerce/team-checkout

[animesh1987]

Can we use a typeguard here and avoid the as keyword please?

[davidchin]

Yes good spot, I made some tweaks to the type so I no longer need to use as. 🙂

[snaderiBC]

Thanks for the reference to the documentation 👍

[bc-peng]

Hi @bigcommerce/team-checkout , I'm going to revert this PR because this line is not working in production and stopping Sentry from logging any issue.

An example of a production error message:

Refused to create a worker from 'blob:https://checkout.solostove.com/5837bd07-3018-47d1-8af1-50e16ed86d04' because it violates the following Content Security Policy directive: "script-src 'none'". Note that 'worker-src' was not explicitly set, so 'script-src' is used as a fallback.

[davidchin]

After more thorough testing and research, I found out that the proposed solution won’t work. Although Sentry SDK allows multiple client instances for different accounts, many of its features (a.k.a. integrations) only works with the primary client. For example, only the primary client includes breadcrumbs in its error logs, and reports uncaught exceptions. It also won’t work if other client instances are constructed using a different SDK version. This is because all of the client instances actually share the same underlying __SENTRY__ global variable. Several issues have been reported regarding the limitation of running multiple client instances (e.g.: getsentry/sentry-javascript#3271, getsentry/sentry-javascript#3268, getsentry/sentry-javascript#2732 etc…). Until Sentry SDK has a better support for multiple client instances, I think the only way around this problem is to recommend merchants to not to initialise their own client instance on the checkout page if they are using the default OOPC.