A stopped workflow stage should show its child stages as stopped too
维护者通常 1 天内回复
@lavaman131 已经在做这个了。
开始于 2026年10月16日。
评估
这个 Issue 还没有评估数据。
描述
When a workflow run stops, its run card in Chat shows the stopped stage as stopped, but the stages under it keep their last status, such as running or queued. The card then reads as though work is still going on inside a run that has ended.
Steps to reproduce
- Start a workflow run from a document's Planner whose stages have child stages, for example a stage that fans out into several sub-stages.
- While a parent stage and its children are running, stop the run. Ending the Planner's connection or deleting the document also stops it.
- Look at the run card in Chat (
apps/web/src/chat/run-card.tsx).
Expected: every stage under a stopped stage shows stopped too, or a muted "not run" for ones that never started. The tree should agree with its parent, and no spinner should keep going under a stopped stage.
Actual: the parent shows stopped, while its children still show running or queued, sometimes with an active spinner.
Suggested fix
- When the card renders a stage whose status is stopped, failed or cancelled, show each descendant that hasn't reached its own end state as stopped. A descendant that already finished (done or failed) keeps its own status.
- Do this where the card builds its stage tree from the Planner's run report, so it applies however the report arrived (live update or reload). Optionally apply the same rule where the server stores the report (
packages/protocol/chat.d.ts). - Add a unit test: a stopped parent with running, queued and done children renders stopped, stopped and done.
- Add a design-audit plate: extend
design-audit/plates/workflow-runs.tsxwith a stopped run that has nested stages.
Assistant-workflow: inline
Assistant-duration: unmeasured
Assistant-verification: manual unavailable: UX feedback from lavaman131 after a run stopped mid-stage on the hosted instance; not reproduced locally
Co-authored-by: lavaman131
- 主要语言
- TypeScript
- 星标
- 406
- 派生
- 24
- 平均合并
- 12 小时 42 分钟
- 30 天内合并 PR
- 416
环境准备
- 提供 Dockerfile 或 Docker Compose 文件
- 没有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
githubnext/chopin 的其他 Issue
-
documentation triage/human-response
难度 2/5 1-3 小时 新手友好度 74/100
githubnext/chopin#149 · 3 条评论 ·
维护者通常 1 天内回复
-
enhancement
难度 3/5 半天 新手友好度 45/100
githubnext/chopin#597 ·
维护者通常 1 天内回复
-
enhancement
难度 4/5 3-5 天 新手友好度 30/100
githubnext/chopin#596 ·
维护者通常 1 天内回复
-
enhancement
难度 5/5 一周以上 新手友好度 12/100
githubnext/chopin#595 ·
维护者通常 1 天内回复
-
enhancement triage/human-response
难度 4/5 3-5 天 新手友好度 55/100
githubnext/chopin#203 · 2 条评论 ·
维护者通常 1 天内回复
查看 githubnext/chopin 的全部 Issue
相似的 Issue
-
bug engine
难度 2/5 1-3 小时 新手友好度 86/100
frostney/GocciaScript#1746 ·
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 67/100
agilepathway/label-checker#739 · 4 条评论 ·
维护者通常 1 天内回复
-
难度 1/5 1 小时以内 新手友好度 68/100
CopilotKit/OpenBot#800 ·
维护者通常 1 天内回复
-
Endpoint links in the tag operations list are below the 24px target size可能已有人在做 @AdzerKI 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 79/100
ehmpathy/rhachet-roles-bhuild#471 ·
维护者通常 1 天内回复