feat(cloudflare)!: Replace enableRpcTracePropagation with rpcTracePropagationTargets - #23486
Draft
JPeer264 wants to merge 2 commits into
Draft
feat(cloudflare)!: Replace enableRpcTracePropagation with rpcTracePropagationTargets#23486JPeer264 wants to merge 2 commits into
JPeer264 wants to merge 2 commits into
Conversation
…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>
Contributor
size-limit report 📦
|
…racePropagationTargets
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
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
tracePropagationTargetsand 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 consistentrpcTracePropagationTargetsis 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 #23233We now remove the
enableRpcTracePropagation: booleanentirely with a allow listrpcTracePropagationTargetsoption, that is empty by default and is therefore the equivalent ofenableRpcTracePropagation: false(in a later PR we have a prefilled allowlist, like in the browser, when users do have our Vite plugin enabled).rpcTracePropagationTargetsonly 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 overruleenableRpcTracePropagationwhenrpcTracePropagationTargetsis set (so the allow list is stronger than enabling it for everything - the receiving worker won't change for the backport)Clanker description:
enableRpcTracePropagation: truepropagated trace context to every Durable Object namespace and service binding onenv. 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.rpcTracePropagationTargetsnames the bindings to propagate to instead, mirroringtracePropagationTargets. 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.
extractRpcMetaonly strips a trailing argument that actually carries__sentry_rpc_meta__, so a call arriving without metadata is untouched.