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

Create versioned global sentry carrier object #12188

Closed
Lms24 opened this issue May 23, 2024 · 0 comments · Fixed by #12206
Closed

Create versioned global sentry carrier object #12188

Lms24 opened this issue May 23, 2024 · 0 comments · Fixed by #12206
Assignees
Labels
Package: core Issues related to the Sentry Core SDK Type: Improvement

Comments

@Lms24
Copy link
Member

Lms24 commented May 23, 2024

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:

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 object
    acs: {...}
    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.

@Lms24 Lms24 self-assigned this May 23, 2024
@Lms24 Lms24 added the Package: core Issues related to the Sentry Core SDK label May 23, 2024
Lms24 added a commit that referenced this issue May 28, 2024
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Package: core Issues related to the Sentry Core SDK Type: Improvement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant