[Flaky CI]: Cloudflare Integration Tests - suites/tracing/durableobject/test.ts > handles consecutive RPC calls without throwing "RPC receiver does not implement method" error

[github-actions]

Flakiness Type

Other / Unknown

Name of Job

Cloudflare Integration Tests

Name of Test

suites/tracing/durableobject/test.ts > handles consecutive RPC calls without throwing "RPC receiver does not implement method" error

Link to Test Run

https://github.com/getsentry/sentry-javascript/actions/runs/28356188139/job/84000348473

---

This issue was automatically created.

[linear-code]

JS-2881

[github-actions]

🤖 Automated fix attempt — aborting without a PR.

I investigated this flaky test but did not produce a fix, because I could not identify a small, low-risk change that attacks the actual root cause without loosening the regression coverage this test exists to provide.

Analysis

The test (suites/tracing/durableobject/test.ts) makes two consecutive GET /hello requests and waits — in unordered() mode — for two sayHello RPC transaction envelopes.

Tracing through the harness (runner.ts):

• In unordered mode, envelopes that don't match the expectation (e.g. the worker's own fetch transactions) are silently skipped and do not reject the run. So a spurious match or an extra/ordering issue is not the failure mode.
• The only way this test fails is a 30s timeout — i.e. fewer than two sayHello transactions reach the mock Sentry server.

A sayHello transaction is only created when Sentry RPC metadata is present on the call. appendRpcMeta() (packages/cloudflare/src/utils/rpcMeta.ts) only appends that metadata if (traceData['sentry-trace']) — i.e. only when the worker has an active trace at the moment it invokes stub.sayHello(). The DO-side wrapper (packages/cloudflare/src/durableobject.ts) then only creates a span when that metadata is found (extractRpcMeta).

So the most likely root cause of this flake is an intermittent loss of the active trace / RPC metadata on one of the two consecutive calls (a trace-propagation or cold-start race in the Cloudflare SDK), which results in one sayHello transaction never being emitted → timeout.

Why no PR

• This points to a product-level propagation race, not a test-harness defect. A correct fix would live in the SDK and needs the failing run's logs (and ideally local reproduction) to pin down — beyond a small, statically-verifiable change.
• The only test-only "fixes" available — loosening the assertion or skip-ing the test — would remove the regression coverage for Cloudflare durable objects instrumentation throwing The RPC receiver does not implement the method "METHOD_NAME error #17127 (the "RPC receiver does not implement method" bug) that this test exists to guard. That's not an acceptable fix.

I could not access the CI logs in this run to confirm the exact failure signature, so I'm deferring to a human rather than committing a speculative change.