Skip to content

Create versioned global sentry carrier objectΒ #12188

@Lms24

Description

@Lms24

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.

Metadata

Metadata

Assignees

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions