@sentry/cloudflare 11: only the first request per isolate reports errors; later captures emit no envelope

Start at the withSentry entry point and inspect wrapRequestHandlerWithInit, especially the waitUntil?.(flushAndDispose(client)) lifecycle described in the report. Reproduce the issue with the provided concurrent burst and beforeEnvelope hook, then verify that reused isolates produce an envelope and transport request for every captured exception without an explicit flush.

Version

@sentry/cloudflare 11.0.0 — regression from 10.75.3, which is unaffected.

Summary

In a Workers fetch handler wrapped with withSentry, only the first request an isolate serves reports errors. Every subsequent request on that same isolate captures an exception that never becomes an envelope — no transport request is made, nothing reaches Sentry, and nothing is logged.

The failure is silent in both directions. On a failing request the SDK still reports itself healthy:

{"initialized":true,"hasClient":true,"enabled":true,"transport":true}

captureException() returns an event id as usual. Only a beforeEnvelope hook reveals that no envelope is ever produced.

Under production traffic, where an isolate serves many requests, this drops the large majority of errors.

Repro

A fetch handler that captures an exception, plus a module-scope counter so each log line says which isolate served the request and how many it had already served:

import * as Sentry from '@sentry/cloudflare';

let isolate: string | undefined;
let served = 0;

const handler = {
  async fetch(request: Request, env: Env, ctx: ExecutionContext) {
    if (!isolate) isolate = crypto.randomUUID().slice(0, 8);
    const client = Sentry.getClient();
    console.log('diag', JSON.stringify({
      isolate, n: ++served,
      initialized: Sentry.isInitialized(),
      hasClient: Boolean(client),
      transport: Boolean(client?.getTransport()),
    }));
    client?.on('beforeEnvelope', () => console.log('envelope', isolate, served));
    client?.on('afterSendEvent', (e, r) => console.log('sent', e.event_id, r?.statusCode));

    Sentry.captureException(new Error('probe'));
    return new Response('ok', { status: 500 });
  },
} satisfies ExportedHandler<Env>;

export default Sentry.withSentry(
  (env: Env) => ({ dsn: env.SENTRY_DSN, tracesSampleRate: 0 }),
  handler,
);

Deploy, then drive it with concurrent bursts so isolates are reused (sequential curls each got a fresh isolate and all succeeded — reuse is required to see it):

for round in 1 2 3; do
  for i in $(seq 1 10); do curl -s -o /dev/null "$URL/probe?i=$round-$i" & done
  wait
done

Read the results with wrangler tail --env <env> --format json and group by isolate / n.

Results

Same Worker, same burst, same deploy pipeline — only the SDK version differs.

SDK	n=1	n>1
10.75.3	8/8 delivered	5/5 delivered (n=2, n=3)
11.0.0	13/13 delivered	0/16 delivered (n=2…6)

One isolate under 11.0.0, verbatim:

isolate 809886ef  n=1  envelope ✅
                  n=2  none     ❌
                  n=3  none     ❌
                  n=4  none     ❌
                  n=5  none     ❌
                  n=6  none     ❌

29 invocations across 16 isolates on 11.0.0; the correlation with n has no exceptions.

Suspected cause

Not verified, offered as a starting point: wrapRequestHandlerWithInit ends the request with waitUntil?.(flushAndDispose(client)), and the client object demonstrably survives isolate reuse — registering a hook per request causes a later request to log earlier requests' hook callbacks, and the same event_id is reported under two different request labels. A client disposed by request n then appears to be reused by request n+1, where it still passes isInitialized() / getClient() / getTransport() but emits no envelope.

Two things that make this easy to miss

1. An explicit await Sentry.flush() inside the handler masks it entirely — the event is sent during the request, before any dispose. A probe written with a flush shows 100% delivery and hides the bug.
2. Every health signal stays green. isInitialized, getClient, getTransport, and the return value of captureException are all indistinguishable between a delivering and a non-delivering request.

Environment

• @sentry/cloudflare 11.0.0 vs 10.75.3
• Cloudflare Workers, compatibility_date 2026-08-15 (so nodejs_compat is on by default)
• Hono 4.13.8; the capture happens in Hono's onError, but the route is an ordinary fetch handler under withSentry
• tracesSampleRate: 0
• Migration followed as documented: the only change for this usage was replacing sendDefaultPii with dataCollection. Nothing in the v10→v11 guide or the 11.0.0 release notes mentions client lifecycle, disposal, or isolate reuse.