Repository navigation
Work around node's hard limit of 1024 diagnostics channels #22302
Description
Activity
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.
- 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:
- added 9 commits that reference this issue
on Jul 25, 2026
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
__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.