fix(devkit): add timing guidance to TaskResult and remove unintentional spread#34996
Merged
Conversation
✅ Deploy Preview for nx-docs ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
✅ Deploy Preview for nx-dev ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Contributor
|
View your CI Pipeline Execution ↗ for commit 03df73e
☁️ Nx Cloud last updated this comment at |
AgentEnder
approved these changes
Mar 24, 2026
barbados-clemens
approved these changes
Mar 24, 2026
FrozenPandaz
requested changes
Mar 24, 2026
…al spread The TaskResult interface's JSDoc now points users to Task.startTime and Task.endTime for timing information. Also removes the ...result spread in the batch execution path that was unintentionally leaking batch-only properties (startTime, endTime) onto the TaskResult object.
llwt
force-pushed
the
fix/task-result-add-timing-properties
branch
from
a3f48ac to
434ced2
Compare
llwt
changed the title
FrozenPandaz
approved these changes
Mar 24, 2026
![nx-cloud[bot]](https://avatars.githubusercontent.com/in/80458?s=60&v=4){kind=small}
Contributor
There was a problem hiding this comment.
Nx Cloud has identified a flaky task in your failed CI:
🔂 Since the failure was identified as flaky, we triggered a CI rerun by adding an empty commit to this branch.
🔔 Heads up, your workspace has pending recommendations ↗ to auto-apply fixes for similar failures.
🎓 Learn more about Self-Healing CI on nx.dev
…al spread The TaskResult interface's JSDoc now points users to Task.startTime and Task.endTime for timing information. Also removes the ...result spread in the batch execution path that was unintentionally leaking batch-only properties (startTime, endTime) onto the TaskResult object. [Self-Healing CI Rerun]
FrozenPandaz
pushed a commit
that referenced
this pull request
Mar 26, 2026
## Current Behavior The `TaskResult` interface exported from the devkit is missing `startTime` and `endTime` properties. At runtime, these properties are present on `TaskResult` objects — set by the task orchestrator during execution and consumed by multiple lifecycle implementations (profiling, timings, history, store-run-information) — but the public type does not declare them. This means the [TaskResult reference docs](https://nx.dev/docs/reference/devkit/TaskResult) don't show these fields. ## Expected Behavior The `TaskResult` interface includes optional `startTime` and `endTime` properties (Unix timestamps) matching what is actually present on runtime objects. The generated devkit reference docs will now include these fields. ## Related Issue(s) N/A (cherry picked from commit 6cc8735)
Contributor
|
This pull request has already been merged/closed. If you experience issues related to these changes, please open a new issue referencing this pull request. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Current Behavior
The
TaskResultinterface has no JSDoc guidance about where to find task timing information. Users looking at the TaskResult reference docs don't seestartTime/endTimeand have no indication that timing is available on the nestedTaskobject.Additionally, the batch execution path in
task-orchestrator.tsuses...resultto spread the batchTaskResult(frommisc-interfaces.ts) onto the lifecycleTaskResult, which unintentionally leaksstartTime,endTime, andsuccessproperties onto the object. This only happens for batch tasks, not for regular tasks, making the behavior inconsistent.Expected Behavior
TaskResultJSDoc now points users toTask.startTimeandTask.endTimefor timing information, which will surface on the generated reference docs...resultspread is removed from the batch path so that only the intendedTaskResultproperties (code,task,status,terminalOutput) are set — timing stays on theTaskobject where it belongs (already copied viatask.startTime = result.startTime/task.endTime = result.endTimeon the lines above)Related Issue(s)
N/A