bug: dashboard File column mis-attributes a task that is imported by another task file

Đang mở
  • Có gì không ổn?
#4,495 0 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.

  • #4504 của @okxint — đã đóng, không merge

Đá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
35/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Đình trệ
Công nghệ
node.js, typescript
Lĩnh vực
build-system, tooling

Hướng nghiên cứu

Start by reading packages/cli-v3/src/build/bundle.ts and packages/cli-v3/src/indexing/registerResources.ts to follow how build outputs are imported and file context is set; then inspect registerTaskMetadata in packages/core/src/v3/resource-catalog/standardResourceCatalog.ts. Reproduce with the child.ts and parent.ts example in the issue. Done means the dashboard File column and task filePath identify the file where each task is defined, including when another task imports it.

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

Mô tả

Provide environment information
  System:
    OS: Windows 11 10.0.26200
    CPU: (4) x64 Intel(R) Xeon(R) Platinum 8272CL CPU @ 2.60GHz
    Memory: 4.71 GB / 15.95 GB
  Binaries:
    Node: 22.16.0
    npm: 10.9.2
  Packages:
    trigger.dev CLI: 4.5.8
    @trigger.dev/sdk: 4.5.8
    runtime: node-22
Describe the bug

The File column in the dashboard's task list (and the corresponding filePath on the task) shows the wrong file for any task that is statically imported by another task file. It reports the importing file rather than the file the task is defined in.

Concretely, in my project the task enrich-company-record is defined in trigger/enrich-company-record.ts, but the dashboard lists it under trigger/reconcile-harmonic-watchlist.ts — one of five other task files that import a helper from it.

Expected: the file the task is defined in.

Impact is cosmetic — routing/execution keys off the task id, so nothing misbehaves at runtime; it's just a wrong file reference/deep-link in the UI. Filing it because the cause turned out to be precise.

Cause

The build runs esbuild with splitting: true (packages/cli-v3/src/build/bundle.ts). Every file under a dirs entry is its own entry point, so a task module that is also imported by sibling task files gets hoisted into a shared chunk instead of staying in its own entry bundle.

Indexing then imports each build entry in order, setting a file context around the import:

// packages/cli-v3/src/indexing/registerResources.ts
for (const file of buildManifest.files) {
  resourceCatalog.setCurrentFileContext(file.entry, file.out);
  const [error, _] = await tryImport(file.out);
  resourceCatalog.clearCurrentFileContext();
  ...
}

and whatever registers during that import is stamped with that entry's path:

// packages/core/src/v3/resource-catalog/standardResourceCatalog.ts — registerTaskMetadata
this._taskFileMetadata.set(task.id, { ...this._currentFileContext });

buildManifest.files is built by iterating result.metafile.outputs, which is not the sorted entry-point order. So the shared chunk — and with it the task() call — evaluates during whichever importing entry happens to come first, and that entry wins the attribution. The task's own entry point is imported later, but the chunk is already in the ESM module cache, so it never re-registers and the attribution is never corrected.

In my build, trigger/reconcile-harmonic-watchlist.ts was index 3 in metafile.outputs and trigger/enrich-company-record.ts was index 31 — hence the observed mis-attribution. Confirmed by inspecting a trigger deploy --dry-run build: the schemaTask({ id: "enrich-company-record" }) call is emitted into a shared chunk-*.mjs, which trigger/reconcile-harmonic-watchlist.mjs imports.

A sibling task in the same project that nothing imports (dedupe-deals-list-entry, triggered only by id) stays in its own entry bundle and is attributed correctly — consistent with the above.

Code is unchanged on v4.5.9.

Reproduction repo

n/a — my project is private, but it reproduces from an empty project with the two files below; happy to push a repro repo if that's needed.

To reproduce

Two task files where one imports the other:

// trigger/child.ts
import { task } from "@trigger.dev/sdk";

export const child = task({
  id: "child",
  run: async () => {},
});

export const fanChild = () => child.trigger({});

// trigger/parent.ts
import { task } from "@trigger.dev/sdk";
import { fanChild } from "./child";

export const parent = task({
  id: "parent",
  run: async () => {
    await fanChild();
  },
});

Deploy (or run trigger dev) and look at the task list: task child is listed with File = trigger/parent.ts.

Note the ordering is metafile.outputs order, not alphabetical, so which importer wins varies by project — with a single importer as above it is deterministic.

Additional information

The build metafile already carries the chunk → source mapping needed to resolve the true defining file, so attribution could be corrected post-index without changing the import strategy.

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.