You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the recent v8 release (but also in the past with previous majors) we changed a couple of properties on the global globalThis.__SENTRY__ carrier object. For example, the APIs on .hub and .acs changed, causing issues like #12155, #12054 or (indirectly) #12179.
Solution Brainstorm
Our idea to work around most of these problems is to create version properties on the __SENTRY__ object:
globalThis.__SENTRY__={version: '8.3.0',// <-- this can be used by e.g. spotlight or the loader script to access the "correct" key'8.3.0': {// <-- SDK adds this along with `version` when first populating the carrier objectacs: {...}stack: {...}}acs: {...}// <-- older SDKs can still put their version of acs, hub, etc. onto the carrier object
hub: {...}}
caveat: There's still potential for race conditions who gets to write version. I'm not sure what heuristic we choose here but we have this problem today as well, just on a broader level. Some ideas:
The first one to populate .version wins. Maybe this is good enough, it's definitely the easiest and most bundle-size efficient heuristic
Newest SDK wins. More bundle size (semver comparison); no-one guarantees that the "main" SDK is in fact the one with the highest version
Add init option or API to mark SDK as main SDK. If set, it can override .version if it's already populated. Can of course be abused 🙃
Additionally, we can also use this to log a warning if we detect multiple props that suggest 2+ initialized SDKs.
The text was updated successfully, but these errors were encountered:
This PR implements a versioned Sentry carrier as described in #12188.
The idea is that SDKs can from now on access their global Sentry
instance and thereby no longer overwrite or interfere with potentially
other SDKs (e.g. 3rd party libraries, scripts, etc).
Internally, SDKs can access their carrier via the
`window.__SENTRY__[SDK_VERSION]`. Externally (spotlight, loader script)
via `window.__SENTRY__[window.__SENTRY__.version]`.
---------
Co-authored-by: Francesco Novy <francesco.novy@sentry.io>
Problem Statement
With the recent v8 release (but also in the past with previous majors) we changed a couple of properties on the global
globalThis.__SENTRY__
carrier object. For example, the APIs on.hub
and.acs
changed, causing issues like #12155, #12054 or (indirectly) #12179.Solution Brainstorm
Our idea to work around most of these problems is to create version properties on the
__SENTRY__
object:caveat: There's still potential for race conditions who gets to write
version
. I'm not sure what heuristic we choose here but we have this problem today as well, just on a broader level. Some ideas:.version
wins. Maybe this is good enough, it's definitely the easiest and most bundle-size efficient heuristic.version
if it's already populated. Can of course be abused 🙃Additionally, we can also use this to log a warning if we detect multiple props that suggest 2+ initialized SDKs.
The text was updated successfully, but these errors were encountered: