Repository navigation
Conversation
Contributor
size-limit report 📦Compared: 2c3a3b2 (PR test merge using develop at b722d3c) Against: b722d3c (develop) · base run #64026 ✅ 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 |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
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
from
October 25, 2026 11:39
1efb56d to
a831f0a
Compare
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>
JPeer264
force-pushed
the
jp/cloudflare-native-trace-id-events
branch
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. 1 not successful, 66 successful. See the run.
Successful checks
|
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
This continues the trace that Cloudflare starts for each invocation (fetch, scheduled, queue and email handlers, and
WorkerEntrypointRPC methods). Errors, logs and spans then have the same trace id as the Cloudflare spans in Workers Observability, also withtracesSampleRate: 0. An incoming Sentry trace (sentry-traceheader or RPC trace data) still has precedence when the SDK continues it.Most of the changed lines are tests. On new runtimes the worker segment has the Cloudflare span as parent, so the Durable Object tests now find the Durable Object segment by its parent.
Sampling decisions
The SDK continues only invocations that Cloudflare traces, but
tracesSampleRatestill decides. The alternative is to pass the Cloudflare decision on assampled, so that Sentry keeps the same traces as Cloudflare.Open question
With a Cloudflare traces destination to Sentry and
tracesSampleRateabove 0, Cloudflare and the SDK both send spans for the request. This PR puts them in 1 trace instead of 2, but Sentry still gets and bills these spans 2 times. Is a docs note enough, or do we want an option to leave out the SDK spans that Cloudflare also makes (the SDK cannot see if a destination exists)?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 with
tracesSampleRate: 0, in the Cloudflare trace: https://sentry-sdks.sentry.io/explore/traces/trace/666e09b1979b18724b8fd77faed99e1b/?project=4510555608449024&statsPeriod=14dSame error without this PR, in its own trace: https://sentry-sdks.sentry.io/explore/traces/trace/bc56b593dcf941c7b21af6216f215dff/?project=4510555608449024&statsPeriod=14d
Root span with the Cloudflare span as parent: https://sentry-sdks.sentry.io/explore/traces/trace/69d9287a44d4faddcda5b6612256e6b6/?project=4510555608449024&statsPeriod=14d