CLI accepts an esbuild version outside its declared range, producing corrupt sourcemaps

Đang mở
  • Có gì không ổn?
#4,801 2 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
48/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Ít trao đổi
Công nghệ
node.js, typescript
Lĩnh vực
backend, build-system

Hướng nghiên cứu

Start by tracing the loadConfig → buildWorker build path and the esbuild version resolved under npm overrides; the report compares emitted sourcemaps across esbuild versions. Then read entryPoints/managed-run-worker.js and otel/utils.ts for the stack-handling impact. Done means addressing a clearly chosen safeguard and verifying it against the reported reproduction, including sourcemap index bounds if validation is chosen.

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

Mô tả

What happened

[email protected] declares esbuild ^0.23.0. Our repo had a root-level npm overrides entry pinning esbuild to 0.25.0, added for GHSA-67mh-4wv8-2f99. npm honours the override, so the CLI bundled with 0.25.0 without warning.

esbuild 0.25.0 has an out-of-bounds source-index regression, fixed in 0.25.1, that drops input sources entries while keeping the mapping indices. Two of our deployed chunks came out internally inconsistent:

  • trigger/slack-attention-agent.mjs.map: 6 sources, mappings referencing index 37
  • a shared ai chunk: 171 sources, mappings referencing index 200

Impact

The worker installs source-map-support globally (entryPoints/managed-run-worker.js). Once a stack contained a frame from either chunk, originalPositionFor threw Error: No element indexed by 6. recordSpanException (otel/utils.ts) and the AI SDK's default error handler (console.error(error)) both read .stack without a guard, so that exception replaced the error being reported.

Every chat.agent turn failed for a week with No element indexed by 6. The original error never surfaced anywhere, including in streamText's onError, which received the substituted message instead. Scheduled tasks on the same deployment kept working, because they never format a stack.

Reproduction

Trigger project on runtime: node-22 with [email protected] and @ai-sdk/[email protected], plus npm overrides: { "esbuild": "0.25.0" }. Build through loadConfig -> buildWorker, then decode each emitted .map and check that every source index is below sources.length:

  • esbuild 0.25.0: 42 of 44 maps valid
  • esbuild 0.23.1: 44 of 44
  • esbuild 0.28.2: 44 of 44

Suggested changes

  1. Warn or fail when the resolved esbuild version falls outside the CLI's declared range. This alone would have surfaced the problem on the first deploy.
  2. Validate emitted sourcemaps before imaging. Checking index bounds is cheap, and the corruption is otherwise invisible until something throws.
  3. Guard .stack access in error reporting so a malformed map cannot replace the error being reported.

Happy to open a PR for 1 or 3.

Ngôn ngữ chính
TypeScript
Star
16.5k
Fork
1.5k
Merge trung bình
1 ngày 15 giờ
Pull request đã merge (30 ngày)
17

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

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

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 triggerdotdev/trigger.dev

Tất cả issue của triggerdotdev/trigger.dev

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.