Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#24,762 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
58/100
Tipo de issue
Error
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
typescript
Área
backend, cloud

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Bug Cloudflare Workers Waiting for: Product Owner
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.
Lenguaje dominante
TypeScript
Estrellas
8.7k
Forks
1.9k
Merge medio
1 d 15 h
PR fusionados (30 d)
523

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de getsentry/sentry-javascript

Todos los issues de getsentry/sentry-javascript

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.