[cloudflare] Events captured in detached work inside Durable Objects are silently dropped (per-invocation client disposal + flush-only transport)

[Soju06]

Is there an existing issue for this?

• I have checked for existing issues https://github.com/getsentry/sentry-javascript/issues
• I have reviewed the documentation https://docs.sentry.io/
• I am using the latest SDK release https://github.com/getsentry/sentry-javascript/releases

How do you use Sentry?

Sentry Saas (sentry.io)

Which SDK are you using?

@sentry/cloudflare

SDK Version

10.62.0

Framework Version

wrangler 4.113.0, compatibility_date 2026-06-16, compatibility_flags = ["nodejs_compat"]

Link to Sentry event

(events never arrive — that is the bug; org stats show 0 received / 0 filtered for the affected captures)

Reproduction Example/SDK Setup

Durable Object instrumented with instrumentDurableObjectWithSentry. The DO's fetch handler kicks off background work that outlives the invocation — a common DO pattern (queue drains, agent runloops; e.g. the agents SDK runs "fibers" exactly like this):

class RoomBase extends DurableObject {
 async fetch(request) {
 // fire-and-forget continuation (same shape as agents-SDK fibers)
 void (async () => {
 await new Promise((r) => setTimeout(r, 3000));
 Sentry.captureException(new Error("captured from detached work"));
 })();
 return Response.json({ ok: true });
 }
}
export const Room = instrumentDurableObjectWithSentry(sentryOptions, RoomBase);

Deployed verbatim (minus names) and verified: the event never arrives — not delayed, never. captureException inside the detached continuation is a silent no-op. Captures from the fetch handler itself, and even from ctx.waitUntil-registered work, arrive fine in the same worker.

Steps to Reproduce

1. Instrument a DO with instrumentDurableObjectWithSentry.
2. From fetch, start a detached async continuation (not awaited, not passed to ctx.waitUntil) that captures an exception after the invocation settles.
3. Trigger the fetch.

Expected Result

The event is delivered, or at minimum the SDK surfaces (debug log) that a capture hit a disposed client so the drop isn't silent.

Actual Result

Nothing is sent and nothing is logged. Mechanism, as far as we can tell from reading the SDK:

1. wrapRequestHandler / wrapMethodWithSentry create a per-invocation client and dispose it via waitUntil(flushAndDispose(client)) when the invocation settles.
2. The detached continuation inherits the invocation's isolation scope through AsyncLocalStorage, so later captureException calls run against the disposed client.
3. makeCloudflareTransport uses IsolatedPromiseBuffer, so events are only ever transmitted on flush() — any capture that misses its scope's flush window is unrecoverable.

Real-world impact: our production DO (a chat agent on the cloudflare agents SDK, where every turn runs as a detached fiber) reported zero errors for 13 days — every captureException from turn code was dropped — while the same code paths kept logging to Workers Logs. Nothing in the SDK hinted at the drop; we found it by diffing org ingest stats (0 received) against console output.

Two follow-up observations from building a workaround, in case they're useful:

• Workaround that works: wrap the detached body in wrapRequestHandler({ options, request: new Request("https://do.detached/<name>"), context: this.ctx }, body) to give it a body-scoped client. However, in our production DO the wrapper's own teardown flush (waitUntil(flushAndDispose)) still did not deliver — we additionally had to drain the transport explicitly inside the handler (getClient()?.getTransport()?.flush(...)) before it settles. In a minimal DO the teardown path delivered fine, so there seems to be a further interaction (flush-lock vs. long-lived ctx.waitUntil registrations?) we could not minimize. Happy to run diagnostics if useful.
• While doing that we also noticed CloudflareClient.flush() awaits pending-span completion; calling it from inside an active request span therefore always stalls for the full timeout — worth a doc note, since flushing "before the invocation ends" is exactly what a detached-work workaround wants to do.

Feature-ask version of this issue: a supported primitive for detached/background DO work (e.g. Sentry.withDetachedScope(name, fn) that binds a body-scoped client and flushes on settle), plus a debug-mode warning when captureException resolves to a disposed client.

[linear-code]

JS-3127

[andreiborza]

Hi @Soju06, thanks for filing this. @JPeer264 will take a look and get back to you.

[JPeer264]

Hey, sorry for the late reply. This is indeed an issue. I think we have to change some internals for that in order to work. The good news is that it will also improve performance for that.

The main issue is that DurableObjects don't seem to need waitUntil like exported handlers need. Our SDK is currently using waitUntil for both concepts and remove the client right after to prevent memory leaks (as we create a new client on every request). In order to fix that we have to change the way how we create the clients. Best case scenario is that we only have one client per isolate - which would work if we just cache our client and reuse it (and create one if there is none). With that technique we don't have to dispose the client at all. As easy as it sounds we need to test this very carefully to check that all instrumentations still work per request.