Uh oh!
There was an error while loading. Please reload this page.
feat(cloudflare): Propagate traceparent to RPC calls - via fetch - #19991
Conversation
Semver Impact of This PR🟡 Minor (new features) 📋 Changelog PreviewThis is how your changes will appear in the changelog. New Features ✨Core
Deps
Other
Bug Fixes 🐛
Internal Changes 🔧
🤖 This preview updates automatically when you update the PR. |
size-limit report 📦
|
3bd82cc to
71a3936Compare71a3936 to
3097f54CompareLms24
commented
Mar 31, 2026
FYI, #19960 landed and I agree! Right now, our various request instrumentations combine the "logic"/"algorithm" code with platform specific code how to set headers. I think it would be good if we could strip out the algorithm part into a common helper, and only leave the platform-specific parts to the individual instrumentations. From my PoV a good improvement but something we can also tackle at a later point. Happy to leave this up to you :) |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
| const newInit = addTraceHeaders(input, init); | ||
| return fetchFn(input, newInit); |
There was a problem hiding this comment.
m/q: is this how we add our tracing headers in our core/browser fetch instrumentation as well? Just wanted to double check because injecting headers into fetch arguments is a bit tricky with the various forms of input and init and the precedence.
I think adding headers to init is fine. Though us deep-copying headers from input to init, and then init again might be unexpected if one of the objects is reused by users across multiple requests. Anyway, not saying something is off but that we should double check that this is how we do it in the other SDKs as well.
There was a problem hiding this comment.
Fair enough, that would be indeed a bad behavior - I'll change the behavior to match the others
There was a problem hiding this comment.
@Lms24 the headers are now attached with the same function as the other SDKs: _INTERNAL_getTracingHeadersForFetchRequest.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
@Lms24 I just reworked the way how tracing headers are generated. I actually exported
|
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
node-overhead report 🧳Note: This is a synthetic benchmark with a minimal express app and does not necessarily reflect the real-world performance impact in an application.
|
part of #15942 This is a basic instrumentation for `WorkerEntrypoint`. There is no extra `instrumentWorkerEntrypoint` exported, and should work directly with `withSentry` OOTB: ```js class MyWorker extends WorkerEntrypoint {} export default Sentry.withSentry(() => ({}), MyWorker) ``` To support the full `WorkerEntrypoint` there is the need to instrument [RPC methods](#16898). Without that we can't fully support `WorkerEntrypoint`s but just the basics of it. This can be added once #19991 lands (it is safe to review now and instrument the env in a separate PR) --- If you look at the instrumentations themselves, there is no `isInstrumented` or `markAsInstrumented`. The reason is that on the one hand this is not required, as every request is spawning a new instance of the `WorkerEntrypoint` and on the other hand it wouldn't work as it would mark it as instrumented, but on the request the `fetch` is overridden and not instrumented.
This PR is an extraction of #19991 It basically exports `getTracingHeadersForFetchRequest`, which was previously only exported for testing, but offers a great functionality if you want to add tracing headers to a request. I renamed it as `addTracingHeadersToFetchRequest` sounded a little misleading, as it didn't really add headers to the request, as it returned the extracted headers from the request (or init, if there are any). ### Open question I added `@hidden` and `@internal` to it, not sure if this is an approach we follow. I'm ok to remove it from the jsdoc
bc033a9 to
f62418dComparef62418d to
179ec14CompareUh oh!
There was an error while loading. Please reload this page.
…pagation (#20345) follow up to #19991 It is better to release it first with an option to be enabled, that would then also be in line with #20343, otherwise `.fetch()` RPC calls would work without any option and the actual Cap'n'Proto RPC calls wouldn't work without. That would be an odd experience. ### New option: `enableRpcTracePropagation` > `instrumentPrototypeMethods` has been deprecated in favor of `enableRpcTracePropagation` Replaces the deprecated `instrumentPrototypeMethods` option with a clearer name that describes what it actually does. This option must be enabled on **both** the caller (Worker) and receiver (Durable Object) sides for trace propagation to work. It is also worth to mention that the implementation of "instrumenting prototype methods" has changed to a Proxy. ```ts // Worker side export default Sentry.withSentry( (env) => ({ dsn: env.SENTRY_DSN, enableRpcTracePropagation: true, }), handler, ); // Durable Object side export const MyDurableObject = Sentry.instrumentDurableObjectWithSentry( (env) => ({ dsn: env.SENTRY_DSN, enableRpcTracePropagation: true, }), MyDurableObjectBase, ); ```
…pagation (#20345) follow up to #19991 It is better to release it first with an option to be enabled, that would then also be in line with #20343, otherwise `.fetch()` RPC calls would work without any option and the actual Cap'n'Proto RPC calls wouldn't work without. That would be an odd experience. ### New option: `enableRpcTracePropagation` > `instrumentPrototypeMethods` has been deprecated in favor of `enableRpcTracePropagation` Replaces the deprecated `instrumentPrototypeMethods` option with a clearer name that describes what it actually does. This option must be enabled on **both** the caller (Worker) and receiver (Durable Object) sides for trace propagation to work. It is also worth to mention that the implementation of "instrumenting prototype methods" has changed to a Proxy. ```ts // Worker side export default Sentry.withSentry( (env) => ({ dsn: env.SENTRY_DSN, enableRpcTracePropagation: true, }), handler, ); // Durable Object side export const MyDurableObject = Sentry.instrumentDurableObjectWithSentry( (env) => ({ dsn: env.SENTRY_DSN, enableRpcTracePropagation: true, }), MyDurableObjectBase, ); ```
relates to #19327
related to #16898 (it is not really closing it as we just add context propagation without adding spans for individual calls. It needs to be defined if we need it)
It is important to know that these RPC calls do only work with the
.fetchcall:This adds RPC fetch calls between:
This works by instrumenting
env(viainstrumentEnv), which then goes over the bindings and see if there is a DurableObject or a normal Fetcher (full list of current bindings: https://developers.cloudflare.com/workers/runtime-apis/bindings/). This got inspired by howotel-cf-workersinstruments their env: https://github.com/evanderkoogh/otel-cf-workers/blob/effeb549f0a4ed1c55ea0c4f0d8e8e37e5494fb3/src/instrumentation/env.tsWith this PR I added a lot of tests to check if trace propagation works (so this PR might look like it added a lot of LoC, but it is mostly tests). So I added it for
scheduleandqueue, but it is not possible foremailandtailwithwrangler dev.Potential things to change
Trace propagagtion
I added the
addTraceHeaders.tshelper, as there is currently no way to reuse the existing logic (it is baked-in into the fetch instrumentations). It would be nice once #19960 lands that we can reuse it in Cloudflare to reuse existing code. I tried to write couple of tests so we don't have duplicated headers.Adding extra spans
So there is actually a guide by OTel to add RPC spans, but was talking with someone from the OTel maintainers and they meant that this wouldn't be necessary as we already have an
http.serverspan from out instrumented DurableObjects (and other resources) - so it wouldn't add much of information.Without RPC span:
With RPC span: