You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
@sentry/cloudflare: Durable Object methods called from the constructor's blockConcurrencyWhile callback are captured as untraced RPC entries #24735
@sentry/cloudflare 10.75.1, with enableRpcTracePropagation: true
Summary
Since #24512, the RPC prototype wrapper instruments any prototype method called while the isolation scope is the default one, in a new trace. The wrapper is installed after construction, but a blockConcurrencyWhile callback started in the constructor runs after that, with no isolation scope. So a method the object calls on itself during initialisation is treated as an untraced RPC entry. If it throws, the error is captured as handled: false with mechanism auto.faas.cloudflare.durable_object, even when the object catches it.
Expected: no error event. The error is caught inside the object.
Actual: one error event for init failed, handled: false, in its own trace.
Observed in real workerd (@cloudflare/vitest-pool-workers). With a raised Error.stackTraceLimit, the capturing frame is the untraced startNewTrace branch in durableobject.ts, wrapping the method called from the constructor's blockConcurrencyWhile callback.
Notes
Declaring internal methods as #private avoids it, because they are no longer on the prototype, and that matches Cloudflare's RPC visibility guidance (https://developers.cloudflare.com/workers/runtime-apis/rpc/visibility/). It may be worth either documenting that, or running constructor-time blockConcurrencyWhile callbacks inside an isolation scope so they are not mistaken for RPC entries.
Activity
linear-code commentedon Sep 25, 2026
JS-3807
JPeer264 commentedon Sep 28, 2026
Hey thanks for writing in. I'm on it and check out how to solve this best
github-actions commentedon Oct 2, 2026
A PR closing this issue has just been released 🚀
This issue was referenced by PR #24829, which was included in the 11.3.0 release.