Work around node's hard limit of 1024 diagnostics channels

[isaacs]

Node has a hard limit of 1024 diagnostics channels being defined. In practice, because a tracing channel is a collection of 5 diagnostics channels bound together in a lifecycle, and because there are a number of internal diagnostics channels defined already, this means that if we even attach listeners to more than 200 tracing channels, the process segfaults.

This will likely be fixed by nodejs/node#64497, but we cannot expect it'll be backported to EOL node versions that the Sentry SDK still supports.

Currently, we expect to define around 50-100 tracing channels with our default built-in integrations set, but that's getting uncomfortably close to the limit. This is made worse by the fact that several popular libraries are already adding tracing channels to their own codebases, and this trend is expected to continue. We are building a tower indoors, and the ceiling is getting closer.

Solution Brainstorms

• (rejected) Update orchestrion to define a single tracing channel name, and make our listeners fancier in how they register and get called. This is likely very complicated, and requires a lot of changes to our current approach, and that of every other APM provider using orchestrion. It'd essentially be a complete overhaul of how orchestrion works. Too risky/costly at this point. Also, although it would prevent the problem likely forever, it would saddle us with a future refactoring to get that complexity out once we no longer support node versions that require this workaround, be unnecessary for other platforms, etc.
• (more promising) Use the __SENTRY_ORCHESTRION__ global defined in worldwide.ts to decide which tracing channels to attach listeners to. This keeps us from defining tracing channels unnecessarily. Downside of this is that there's still a limit, but it gets much further away, and doesn't require any significant refactoring of orchestrion or our listener functions. Also, this does not guard against attaching listeners to native tracing channels provided by libraries, but it does afford us enough breathing room that it's much more tractable. (If enough libraries add tracing channels, we may want to have a similar "was this module loaded?" tracking in our loader hooks, and gate those native-dc integrations on that.)

Note: Not a problem for Bun or Deno. They easily support well over a million defined tracing channels, and I don't think we'll hit their limits any time soon.

[linear-code]

JS-3059

[isaacs]

cc: @timfish

[isaacs]

More thoughts on this:

• What we need is some kind of "attach these listeners when and if the module gets (or has already been) loaded". Right now, we're attaching listeners to all channels right away, which gets us close to the limit. There's a tricky timing issue here, because it can be either:
  • module loads, orchestrion instruments, then integration loads (should listen right away)
  • integration loads (registers intent-to-subscribe, but doesn't subscribe), then module loads, orchestrion instruments, and intent-to-subscribe is resolved by adding subscriptions.
  • integration loads (registers intent-to-subscribe, but doesn't subscribe), module never loads, intent-to-subscribe goes unsatisfied (but that's fine)
• This is still an issue for native-dc integrations. But, if we reduce our orchestrion-driven ones down below the limit, we may be fine until the 1024-limited node versions fall out of our supported range. In any event, that's a problem for a future issue ;)
• Best to address this after the orchestrion ports are done landing, so that it's a clean sweep, rather than having some in-flight still needing to be ported. We have enough room in the limit for that to not be a problem, so it's not exactly urgent, but should probably get in before v11, just to be safe.