What
When node-core is removed in v11, revisit how the diagnostics-channel-injection gate in packages/node/src/sdk/index.ts decides whether tracing is enabled (isDiagnosticsChannelInjectionEnabled() && hasSpansEnabled(options)).
During the aws-sdk orchestrion work (PR #22143) we hit a case where the DC-injection gate runs in _initbefore node-core resolves SENTRY_TRACES_SAMPLE_RATE. On the @sentry/aws-serverless Lambda auto-init path (awslambda-auto.ts), the sample rate is split across two options objects: it's passed into getDefaultIntegrations({ tracesSampleRate }) but NOT into the init({ integrations: [...] }) call. So at the _init gate hasSpansEnabled(options) returns false even though tracing will be on, register() is skipped, the module hooks never install, and spans silently never emit.
A local hasSpansEnabledIncludingEnv helper was added to compensate (peek at the env var at gate time), then removed as a code smell: it duplicated node-core's private getTracesSampleRate env parsing (which also exists in node-core/src/light/sdk.ts), and its name implied a general predicate when it was really a gate-timing shim.
Why
The root cause is architectural and specific to the node → node-core split: the sample rate is resolved late (inside node-core) and split across two options objects on the auto-init path. This disappears when orchestrion becomes the default and node-core goes away in v11, so fixing it now is churn on code with a known expiry. Tracking it here instead.
Options to evaluate in v11
- Decouple
register() from the span gate entirely (installing module hooks is near-free with no subscribers), so the gate no longer needs to predict node-core's env resolution; or - Expose a single shared "tracing enabled (including env)" resolver and dedupe the triplicated
SENTRY_TRACES_SAMPLE_RATE parsing.
Note
The same env blind spot also affects the getAutoPerformanceIntegrations() gate on the auto-init path (it uses plain hasSpansEnabled(options) too), so whatever fix lands should cover both gates. This is currently only reachable via the experimental experimentalUseDiagnosticsChannelInjection() opt-in, so there is no impact on default users today.
What
When node-core is removed in v11, revisit how the diagnostics-channel-injection gate in
packages/node/src/sdk/index.tsdecides whether tracing is enabled (isDiagnosticsChannelInjectionEnabled() && hasSpansEnabled(options)).During the aws-sdk orchestrion work (PR #22143) we hit a case where the DC-injection gate runs in
_initbefore node-core resolvesSENTRY_TRACES_SAMPLE_RATE. On the@sentry/aws-serverlessLambda auto-init path (awslambda-auto.ts), the sample rate is split across two options objects: it's passed intogetDefaultIntegrations({ tracesSampleRate })but NOT into theinit({ integrations: [...] })call. So at the_initgatehasSpansEnabled(options)returnsfalseeven though tracing will be on,register()is skipped, the module hooks never install, and spans silently never emit.A local
hasSpansEnabledIncludingEnvhelper was added to compensate (peek at the env var at gate time), then removed as a code smell: it duplicated node-core's privategetTracesSampleRateenv parsing (which also exists innode-core/src/light/sdk.ts), and its name implied a general predicate when it was really a gate-timing shim.Why
The root cause is architectural and specific to the node → node-core split: the sample rate is resolved late (inside node-core) and split across two options objects on the auto-init path. This disappears when orchestrion becomes the default and node-core goes away in v11, so fixing it now is churn on code with a known expiry. Tracking it here instead.
Options to evaluate in v11
register()from the span gate entirely (installing module hooks is near-free with no subscribers), so the gate no longer needs to predict node-core's env resolution; orSENTRY_TRACES_SAMPLE_RATEparsing.Note
The same env blind spot also affects the
getAutoPerformanceIntegrations()gate on the auto-init path (it uses plainhasSpansEnabled(options)too), so whatever fix lands should cover both gates. This is currently only reachable via the experimentalexperimentalUseDiagnosticsChannelInjection()opt-in, so there is no impact on default users today.