fix(cli): sort bundle output files for deterministic task-to-file attribution - #4504
fix(cli): sort bundle output files for deterministic task-to-file attribution#4504okxint wants to merge 1 commit into
Conversation
🦋 Changeset detectedLatest commit: 5e1f25f The changes in this PR will be included in the next version bump. This PR includes changesets to release 26 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Hi @okxint, thanks for your interest in contributing! This project requires that pull request authors are vouched, and you are not in the list of vouched users. This PR will be closed automatically. See https://github.com/triggerdotdev/trigger.dev/blob/main/CONTRIBUTING.md for more details. |
| "trigger.dev": patch | ||
| --- | ||
|
|
||
| Fix non-deterministic task-to-file attribution when multiple tasks share an output bundle. `Object.entries` iteration order is not guaranteed, so tasks defined in imported files could be attributed to the wrong source file. Files are now sorted by entry path before registration. |
There was a problem hiding this comment.
🟡 Release note text describes internals instead of user impact
The release note for this change is written in implementation terms, naming internal mechanics (Object.entries in .changeset/bundle-deterministic-file-order.md:5) instead of a plain user-facing sentence, so shipped release notes will violate the repository's changeset writing rules.
Impact: Users reading the release notes see internal jargon rather than a clear description of what changed for them.
Rule from AGENTS.md on changeset wording
AGENTS.md states: "Write the description for users, not maintainers. Both changesets and .server-changes/ notes ship verbatim in user-visible release notes. Lead with what changed for the user - one plain sentence describing behavior, not implementation, and never naming internal tools or infra." The current note leads with "non-deterministic task-to-file attribution" and cites Object.entries iteration order and internal registration order.
| Fix non-deterministic task-to-file attribution when multiple tasks share an output bundle. `Object.entries` iteration order is not guaranteed, so tasks defined in imported files could be attributed to the wrong source file. Files are now sorted by entry path before registration. | |
| Tasks now consistently appear under the file they are defined in, instead of sometimes being grouped under a file that imports them. |
Was this helpful? React with 👍 or 👎 to provide feedback.
| } | ||
| } | ||
|
|
||
| files.sort((a, b) => a.entry.localeCompare(b.entry)); |
There was a problem hiding this comment.
🔍 Alphabetical sort makes attribution deterministic but not necessarily correct
Sorting files by entry path only guarantees a stable order; it does not guarantee that a file defining a task is imported before a file that imports it. registerResources (packages/cli-v3/src/indexing/registerResources.ts:11-14) attributes every task registered during an import to the currently-imported entry, so a parent file that sorts earlier than its child (e.g. trigger/a-parent.ts importing trigger/z-child.ts) will still claim the child's tasks. The PR makes the misattribution consistent rather than eliminating it; a real fix would need to attribute tasks by the source file recorded at registration time (or import leaf modules first based on the metafile import graph).
Was this helpful? React with 👍 or 👎 to provide feedback.
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
WalkthroughBundle entry files are now sorted alphabetically by their ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
When
getBundleResultFromBuilditeratesObject.entries(result.metafile.outputs), the order is not guaranteed by the spec. On some Node versions and esbuild configurations, task files appear in arbitrary order. WhenregisterResourcesthen iteratesfilesto attribute tasks to their source, a task defined inchild.ts(imported byparent.ts) can end up attributed toparent.tsif its output appears first — breaking per-file grouping in the dashboard.Fixes #4495.
Change
Sort
filesbyentrypath (alphabetically) after the loop, before returning, so attribution is deterministic regardless ofObject.entriesorder.How to test
Deploy a project that has a parent task importing a child task in a separate file. Confirm both tasks appear under their correct source files in the dashboard across multiple deploys.