feat(cloudflare)!: Replace enableRpcTracePropagation with rpcTracePropagationTargets - #23486
Open
JPeer264 wants to merge 2 commits into
Open
feat(cloudflare)!: Replace enableRpcTracePropagation with rpcTracePropagationTargets#23486JPeer264 wants to merge 2 commits into
JPeer264 wants to merge 2 commits into
Conversation
Copy link
Copy Markdown
Member
Sorry, something went wrong.
…pagationTargets `enableRpcTracePropagation: true` propagated trace context to every Durable Object namespace and service binding on `env`. RPC carries that context as a trailing argument, and only a Sentry-instrumented receiver strips it again, so any receiver the user does not own saw an extra argument. `rpcTracePropagationTargets` names the bindings to propagate to instead, mirroring `tracePropagationTargets`. Strings match a binding name exactly, regular expressions match by pattern. The option is now caller-only. Receivers no longer take a switch: a Durable Object instruments its RPC methods unconditionally, matching what a WorkerEntrypoint already did. `extractRpcMeta` only strips a trailing argument that actually carries `__sentry_rpc_meta__`, so a call arriving without metadata is untouched. BREAKING CHANGE: `enableRpcTracePropagation` is removed. Replace it on the caller with `rpcTracePropagationTargets` listing the bindings you call, and drop it from receivers. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Copy link
Copy Markdown
Contributor
size-limit report 📦
|
Sorry, something went wrong.
…racePropagationTargets
JPeer264
marked this pull request as ready for review
August 23, 2026 06:28
JPeer264
requested review from
andreiborza and
isaacs
and removed request for
a team
August 23, 2026 06:28
Copy link
Copy Markdown
Member
Author
|
bugbot run |
Sorry, something went wrong.
Copy link
Copy Markdown
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 d68e2df. Configure here.
Sorry, something went wrong.
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
Reviewers
At least 1 approving review is required to merge this pull request.
Assignees
1 participant
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 #23233
This PR existed because of this comment: #23363 (comment)
We already have an option tracePropagationTargets and they are set to a safe default list in the browser (because in the browser we can't enable it for all addresses by default). To keep it consistent rpcTracePropagationTargets is the equivalent for RPC calls, while this has the same concerns as the browser - we can't target all RPC calls OOTB, as this would lead to issues as seen in #23233
We now remove the enableRpcTracePropagation: boolean entirely with a allow list rpcTracePropagationTargets option, that is empty by default and is therefore the equivalent of enableRpcTracePropagation: false (in a later PR we have a prefilled allowlist, like in the browser, when users do have our Vite plugin enabled).
rpcTracePropagationTargets only has to be enabled on the sender worker. The receiving worker does not have to do anything, as we automatically detect if there is a payload from us included. If there is, we strip it - it should be safe enough to listen to this by default, as we already have the last RPC parameter properly prefixed.
(when this is being backported to v10, we keep enableRpcTracePropagation: boolean, deprecate it and overrule enableRpcTracePropagation when rpcTracePropagationTargets is set (so the allow list is stronger than enabling it for everything - the receiving worker won't change for the backport)
Clanker description:
enableRpcTracePropagation: true propagated trace context to every Durable Object namespace and service binding on env. RPC carries that context as a trailing argument, and only a Sentry-instrumented receiver strips it again, so any receiver the user does not own saw an extra argument.
rpcTracePropagationTargets names the bindings to propagate to instead, mirroring tracePropagationTargets. Strings match a binding name exactly, regular expressions match by pattern.
The option is now caller-only. Receivers no longer take a switch: a Durable Object instruments its RPC methods unconditionally, matching what a WorkerEntrypoint already did. extractRpcMeta only strips a trailing argument that actually carries __sentry_rpc_meta__, so a call arriving without metadata is untouched.