test(node,browser): Add integration tests for continueTrace and startNewTrace - #22804
test(node,browser): Add integration tests for continueTrace and startNewTrace#22804mydea wants to merge 1 commit into
Conversation
f8a1d7d to
9a6ddf1
Compare
9a6ddf1 to
9a9c4f5
Compare
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit 9a9c4f5. Configure here.
| const headers = await outgoingRequest.allHeaders(); | ||
| expect(headers['sentry-trace']).toMatch(new RegExp(`^${UNSAMPLED_TRACE_ID}-[a-f0-9]{16}-0$`)); | ||
| }, | ||
| ); |
There was a problem hiding this comment.
Missing no-transaction assertions
Medium Severity
Several cases claim a transaction is not emitted (unsampled, deferred with tracesSampleRate=0, TwP / negative parent decisions) but only assert on the error event and outgoing headers. Nothing fails if a transaction is still sent. Flagged because the review rules require an explicit assertion when a payload is expected to be absent.
Additional Locations (2)
Triggered by project rule: PR Review Guidelines for Cursor Bot
Reviewed by Cursor Bugbot for commit 9a9c4f5. Configure here.
There was a problem hiding this comment.
Valid, but this feels pretty minor to me.
4fbbdeb to
4f3087d
Compare
Adds node-integration-tests directly exercising the public `Sentry.continueTrace()` and `Sentry.startNewTrace()` APIs, which previously had no direct coverage in node-integration-tests. `continueTrace` is covered across four incoming-trace variants (sampled, unsampled, deferred sampling decision, and no incoming trace) and three tracing configs (no `tracesSampleRate`, `=1`, `=0`), asserting the continued trace id reaches both the error event and the transaction, that the incoming sampling decision overrides the local rate, and that outgoing propagation carries the continued trace. `startNewTrace` asserts that every root span created within a single callback shares the one new trace id (multiple `startInactiveSpan` plus a `startSpan`), that the new trace is detached from an ambient active span, and that outgoing propagation carries the new trace id — across all three tracing configs. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> test(browser): Add continueTrace + multi-span startNewTrace coverage Adds browser-integration-tests for `Sentry.continueTrace()`, which had no direct coverage (only `dist/` bundle artifacts referenced it). Covers four incoming-trace variants (sampled, unsampled, deferred sampling decision, no incoming trace) across three tracing configs — `tracesSampleRate: 1`, `tracesSampleRate: 0`, and tracing-without-performance — asserting trace-id continuation on transactions and error events, incoming-sampling-decision precedence over the local rate, and outgoing request propagation. `startNewTrace` was already covered for the single-span case, so this adds a focused suite asserting that multiple root spans created within one `startNewTrace` callback all share the single new trace id and remain independent root spans. Also refactors the node `continueTrace`/`startNewTrace` suites to drive the config and variant matrices via `describe.each`/`test.each` instead of nested loops, and widens the runner's `withEnv` to accept `undefined` values so an unset config maps cleanly to TwP mode. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> adjustments and fixes
4f3087d to
c730c52
Compare
isaacs
left a comment
There was a problem hiding this comment.
Looks like this indeed would've caught the issues in the other PR 👍
The failing e2e looks unrelated.
| const headers = await outgoingRequest.allHeaders(); | ||
| expect(headers['sentry-trace']).toMatch(new RegExp(`^${UNSAMPLED_TRACE_ID}-[a-f0-9]{16}-0$`)); | ||
| }, | ||
| ); |
There was a problem hiding this comment.
Valid, but this feels pretty minor to me.


Adds integration tests that directly exercise the public
Sentry.continueTrace()andSentry.startNewTrace()APIs, in both node and browser integration test packages. Before this, no integration test called either API directly — the real-world incoming-trace path (HTTP instrumentation → propagatorextract) was covered, but the manual API surface was not.These land first on
developso the suites are validated against the current implementation. A follow-up stacks theSentryPropagatorsimplification PR on top, where the same node suites guard the refactor (which reroutes these APIs through@sentry/coreand a customSentryTracer).node-integration-tests
continueTraceis covered across four incoming-trace variants — sampled (-1), unsampled (-0), deferred sampling decision (no trailing flag), and no incoming trace — times three tracing configs (notracesSampleRate,=1,=0). It asserts the continued trace id reaches both the error event and the transaction, that an incoming sampling decision overrides the local sample rate, and that outgoing propagation (viagetTraceData()) carries the continued trace.startNewTraceasserts that every root span created within a single callback shares the one new trace id — twostartInactiveSpanplus astartSpan— that the new trace is detached from an ambient active span, and that outgoing propagation carries the new trace id, across all three tracing configs. The multi-root-span assertion specifically guards the OTEL behavior where each root span re-entersstartNewTrace(tracer.ts_startSentrySpan): without a shared remote span context, each root would otherwise mint its own trace id.Both node suites run in ESM and CJS via
createEsmAndCjsTests, with the config/variant matrices driven bydescribe.each/test.each.browser-integration-tests
The browser SDK is non-OTEL, so
continueTrace/startNewTracerun core's implementations directly.startNewTracewas already covered for the single-span case;continueTracehad no direct coverage.continueTracesuites cover the same four incoming variants acrosstracesSampleRate: 1,tracesSampleRate: 0, and tracing-without-performance, asserting trace continuation on transactions/errors and outgoing request propagation.startNewTrace-multiple-spanssuite asserts multiple root spans in one callback share the single new trace id and remain independent root spans.