Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#24,762 1 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
58/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
typescript
Lĩnh vực
backend, cloud

Hướng nghiên cứu

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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.
Ngôn ngữ chính
TypeScript
Star
8.7k
Fork
1.9k
Merge trung bình
1 ngày 15 giờ
Pull request đã merge (30 ngày)
523

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của getsentry/sentry-javascript

Tất cả issue của getsentry/sentry-javascript

Issue tương tự

Thêm issue về TypeScript

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.