Skip to content

Cloudflare v11 potential breaking changes tracking #20682

Closed

Description

@JPeer264

Tracking issue for breaking changes to implement in @sentry/cloudflare for v11.

Documented TODOs in the codebase

Deprecated Options to Remove

Note: Check if we shouldn't remove both options based on #20525

  • Remove instrumentPrototypeMethods option (replaced by enableRpcTracePropagation)
    https://github.com/getsentry/sentry-javascript/blob/ff11476637576fdc820ba08275d0f36f87384762/packages/cloudflare/src/client.ts#L203
    * Gets the effective RPC propagation setting, handling deprecation of `instrumentPrototypeMethods`.
    *
    * Priority:
    * 1. If `enableRpcTracePropagation` is set, use it (ignore `instrumentPrototypeMethods`)
    * 2. If only `instrumentPrototypeMethods` is set, use it with deprecation warning
    * 3. If neither is set, return `false`
    *
    * @returns The effective setting for RPC trace propagation
    */
    export function getEffectiveRpcPropagation(options: CloudflareOptions): boolean {
    const { enableRpcTracePropagation, instrumentPrototypeMethods } = options;
    // If the new option is explicitly set, use it
    if (enableRpcTracePropagation !== undefined) {
    if (instrumentPrototypeMethods !== undefined) {
    DEBUG_BUILD &&
    debug.warn(
    '[Sentry] Both `enableRpcTracePropagation` and `instrumentPrototypeMethods` are set. ' +
    'Using `enableRpcTracePropagation` and ignoring `instrumentPrototypeMethods`.',
    );
    }
    return enableRpcTracePropagation;
    }
    // Fall back to deprecated option with warning
    if (instrumentPrototypeMethods !== undefined) {
    DEBUG_BUILD &&
    debug.warn(
    '[Sentry] `instrumentPrototypeMethods` is deprecated and will be removed in a future major version. ' +

Potential Additional Breaking Changes

  • Make D1 instrumentation opt-in - Tree-shakeable integration to reduce bundle size
  • Consolidate async context strategy initialization - Currently set in multiple places (withSentry, sentryPagesPlugin, instrumentDurableObjectClass)
  • Remove wrapRequestHandler from public API - Low-level internal API. This is used in couple of projects, maybe we still need this

Activity

  1. added this to the 11.0.0 milestone on May 5, 2026
  2. self-assigned this
    on May 5, 2026
  3. linear-code commented on May 5, 2026

    @linear-code
  4. m13v commented on Jun 18, 2026

    @m13v

    the inboundFilters to eventFilters rename and the instrumentPrototypeMethods removal both close cleanly inside the package, but the boundary that list doesn't touch is the consumer's frozen v10 config. once a deprecated option is gone in v11, the failure mode flips from a deprecation warning to a silent no-op on upgrade, since unknown keys just get ignored at init. worth deciding now whether v11 warns on unrecognized options or stays quiet, otherwise people carry dead config across the major and never learn the integration stopped applying.

  5. moved this to Waiting for: Product Owner in GitHub Issues with 👀 3on Jun 18, 2026
  6. moved this from Waiting for: Product Owner to No status in GitHub Issues with 👀 3on Jun 18, 2026
  7. JPeer264 commented on Jun 19, 2026

    @JPeer264
    MemberAuthor

    In theory we remove the types from the config itself, so actually there should be a TypeScript error popping up. It would be silent for everyone who doesn't use TypeScript. Since this would apply also for other SDKs I'm unsure if some extra bytes are worth to check for a dead config (as this would need during runtime if I understood it correctly), while // @ts-check on JavaScript files would potentially solve the issue. Or am I missing something?

  8. JPeer264 commented on Aug 6, 2026

    @JPeer264
    MemberAuthor

    Done. Updated everything relevant in the description

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Projects

Relationships

None yet

Development

No branches or pull requests

Issue actions