Repository navigation
Conversation
Contributor
size-limit report 📦Compared: a5edced (PR test merge using develop at 2b878f1) Against: 2b878f1 (develop) · base run #65743 ✅ Baseline matches: this diff contains only this PR's changes.
|
JPeer264
force-pushed
the
jp/cloudflare-native-trace-id-events
branch
2 times, most recently
from
October 22, 2026 09:57
0d94f79 to
0ac234a
Compare
Member
Author
|
bugbot run |
There was a problem hiding this comment.
✅ Bugbot reviewed your changes and found no new issues!
Comment @cursor review or bugbot run to trigger another review on this PR
Reviewed by Cursor Bugbot for commit 0ac234a. Configure here.
JPeer264
force-pushed
the
jp/cloudflare-native-trace-id-events
branch
2 times, most recently
from
October 27, 2026 15:52
a831f0a to
7c966d8
Compare
Contributor
Optional E2E testsSome optional checks were not successful. They do not block the merge. 4 not successful, 51 successful. See the run.
Successful checks
|
JPeer264
marked this pull request as ready for review
November 9, 2026 10:14
JPeer264
requested review from
andreiborza,
chargome,
msonnb and
mydea
and removed request for
a team
November 9, 2026 10:14
The SDK now reads `ctx.tracing.getActiveSpan().spanContext()` and sets
the propagation context to the Cloudflare trace id and span id. Errors,
logs and spans then use the same trace id as the spans that Cloudflare
exports, also when `tracesSampleRate` is 0. An incoming `sentry-trace`
header keeps precedence. Runtimes without `spanContext()` and invocations
that Cloudflare does not trace keep the current behavior.
`spanContext()` ships in workerd 1.20261009.1, so only the optional CI
job with the latest wrangler runs the new code path. The integration
tests select the expected values of each runtime with
`supports({ minWorkerd })`. The latest wrangler traces every local
invocation, so a root span can have the Cloudflare span as parent, and
the tests find the child segment by its parent instead.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Jan Peer Stöcklmair <jan.peer@sentry.io>
Co-Authored-By: Jan Peer Stöcklmair <jan.peer@sentry.io>
Co-Authored-By: Jan Peer Stöcklmair <jan.peer@sentry.io>
sentry-junior
Bot
force-pushed
the
jp/cloudflare-native-trace-id-events
branch
from
November 11, 2026 14:05
8f1b2b0 to
66599aa
Compare
JPeer264
marked this pull request as draft
November 11, 2026 15:07
Only continue the Cloudflare trace when Sentry tracing is not set up (no tracesSampleRate or tracesSampler), so a trace has a single source and Cloudflare and SDK spans never mix. Co-Authored-By: Jan Peer Stöcklmair <jan.peer@sentry.io>
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
closes #22214
closes JS-3018
Description
When Sentry tracing is not set up (no
tracesSampleRateortracesSampler), this continues the trace that Cloudflare starts for each invocation (fetch, scheduled, queue and email handlers, andWorkerEntrypointRPC methods). Errors and logs then have the same trace id as the Cloudflare spans in Workers Observability. An incoming Sentry trace (sentry-traceheader or RPC trace data) still has precedence.When tracing is set up, the SDK keeps starting its own traces as before. This keeps a single tracing source per trace, so Cloudflare and SDK spans never mix in one trace and Sentry does not get the same request spans twice. We can still add an opt-in to continue the Cloudflare trace with tracing enabled later if there is demand.
tracesSampleRate: 0counts as tracing set up (same check ashasSpansEnabled).Known issues
Span.spanContext(), which ships in workerd 1.20261009.1. Older runtimes keep the current behavior, so only the optional CI job with the latest wrangler runs the new code path.DurableObjectStatehas notracing. A follow-up can readtracingfromcloudflare:workersinstead.Sentry traces
Error without tracing, in the Cloudflare trace: https://sentry-sdks.sentry.io/explore/traces/trace/666e09b1979b18724b8fd77faed99e1b/?project=4510555608449024&statsPeriod=14d (captured with
tracesSampleRate: 0before tracing gated the behavior)Same error without this PR, in its own trace: https://sentry-sdks.sentry.io/explore/traces/trace/bc56b593dcf941c7b21af6216f215dff/?project=4510555608449024&statsPeriod=14d
via Jan Peer Stöcklmair.
--
View Session [Sentry]