fix(workflow): a sibling Failed run is only in Runs — header/timeline never say it failed #1493

Activity

1. Birfy

   added

   bugSomething isn't workingSomething isn't working

   area:uiWeb/desktop UI and copyWeb/desktop UI and copy

   on Oct 27, 2026
2. cursor

   added 2 commits that reference this issue on Oct 27, 2026

   fix(workflow,settings): UI polish pass 5+6 - Progress button, Notific…

   ...

   27f5bee

   fix(workflow,settings): UI polish pass 5+6 - Progress button, Notific…

   ...

   eaaea2c
3. Birfy

   added a commit that references this issue on Oct 27, 2026

   fix(workflow,settings): UI polish passes 4-6 - composer, locale, head…

   ...

   cf72d48
4. Birfy commented on Oct 28, 2026

   

   Birfy

   on Oct 28, 2026

   CollaboratorAuthor

   More actions

   LIVE re-confirm (Asia/Shanghai 2026-10-28) — Failed rows still have no reason

   Same inspection pass on prod tip ~55e1c27a (issue→合入 / PR→合入 via cookie proxy). Expanding the “Runs rows lack … failure reason” note already in this issue:

   Actual: Failed runs (examples seen: #1453, #1422, #1395) show no failure reason in the Runs list or the timeline — only a Failed badge / status. Operator cannot tell why it failed without digging elsewhere.

   Expected: When a run fails, surface a short reason (error / outcome / last node message) on the Runs row and on a timeline failure line.

   This issue’s expected already asks for “Runs rows show time + reason when Failed” and timeline failure + reason — keeping that here instead of a duplicate “no failure reason” issue. Sibling-header visibility remains the other half of this ticket.

   Not filing separately (dedupe). Owner: 「这些问题也要提issue去改」 (t640u).
5. Birfy commented on Oct 28, 2026

   

   Birfy

   on Oct 28, 2026

   CollaboratorAuthor

   More actions

   Written-by: Triage

   agent-ready — reproduced against main at 176d33d034e741b68041c0676da1707001cb6e88 (2026-10-28), not only in the screenshot.

   Why a sibling failure never reaches the room. The client half of this shipped in #1494 (liveStageRuns accepts status === 'failed', the strip paints a Failed chip), but the host never sends a failed run, so that path is dead whenever another run is still live:

   • plugins/workflow/src/service.js:184 — runs: runningOf(lane), and runningOf keeps only live === true && status === 'running' (:203). A run that fails leaves lane.active and lives in lane.last and lane.history only.
   • Repro with the deliverable template: two concurrent runs (maxConcurrent: 2), then end one the way the stop / reap paths do (reset { runId } → endRun). Snapshot: runs = [#1445 running], activeCount = 1, run = #1445 — #1460 appears only as history: [{task, status: 'failed', at}], with no run id and no reason. The header has one strip, exactly as the screenshot.
   • plugins/workflow/client.js:551 — runHistoryRows hardcodes status: 'running' for every row it takes from runs, so a failed run routed through it would read "Running"; Runs (:725) renders neither at nor a reason, which is the second half of this issue.
   • The timeline gap is the silent ending: a step failure logs a line (narrate.js) and reset logs ■ 已停止, but the hand-off catch (service.js:555, endRun → releaseRun) and reap (:1062) / dispose (:1085) archive a run as failed with no log line at all — the 开始 then nothing shape of fix(workflow): every stage chat line is clipped at 240 characters with no way to read the rest (introduced by #1456) #1460.

   Scope going forward (one PR):

   1. service.js — a failed run that is still live and whose task differs from every running run's task stays in the workflow's runs, with what ended it (failure: { code, nodeName?, text?, at }); record that reason wherever a run becomes failed (step failure, stop, hand-off failure, reap/dispose); history rows carry the run id and that reason.
   2. client.js — the strip for a failed run names the reason instead of Waiting for a task; Runs rows show the run's own status (not a hardcoded "Running"), its time, and its reason.
   3. One tone: 'bad' timeline line for an ending that logs none today (hand-off failure, reap).
   4. Tests that fail on the current tree: a service test for the snapshot and the reason record, and a client test for the failed sibling strip plus the Runs row (status, time, reason).

   No blocking conflict. #1507 (a retry leaves duplicate rows for one task) stays open and undecided: this change surfaces a failed run only when its task differs from every running run's task, so a same-task retry still collapses to the running row and #1507 keeps its own question. #1494 merged; no open PR names #1493; no hold; unassigned.
6. Birfy

   added

   agent-readyMaintainer-approved spec: an agent may take it. Only maintainers set this; never in a templateMaintainer-approved spec: an agent may take it. Only maintainers set this; never in a template

   on Oct 28, 2026
7. Birfy commented on Oct 28, 2026

   

   Birfy

   on Oct 28, 2026

   CollaboratorAuthor

   More actions

   Written-by: Triage

   Claimed #1493 — branch fix/1493-failed-sibling-surface, pull request #1562 (Fixes #1493). First step was the reproduction above; the change keeps the failed sibling in workflow/state runs with a failure record, shows it on the strip and its Runs row with time and reason, and writes the timeline line the reap never wrote. Awaiting CI at the tip and a Reviewer PASS.
8. Birfy

   added

   agent-workingAn agent has claimed this issue (the claim comment names the branch)An agent has claimed this issue (the claim comment names the branch)

   and removed

   agent-readyMaintainer-approved spec: an agent may take it. Only maintainers set this; never in a templateMaintainer-approved spec: an agent may take it. Only maintainers set this; never in a template

   on Oct 28, 2026
9. Birfy commented on Oct 28, 2026

   

   Birfy

   on Oct 28, 2026

   CollaboratorAuthor

   More actions

   Written-by: Triage

   Reconcile at 2026-10-28T10:35:25Z: PR #1562 already exists for this issue (claimed 2026-10-28T06:45Z, branch fix/1493-failed-sibling-surface, head 4a0ed7fcb330616b758c0f7bec8863cf7bb59fb7, body Fixes #1493, labelled agent-pr), so agent-ready is removed and this round adds no implementation.

   • The work item is the pull request: green CI at the tip, then a Reviewer PASS at that same tip.
   • The in-flight label is left for its owner; the claim comment above already names the branch and the pull request.
   • One issue, one pull request: no second branch and no second pull request for fix(workflow): a sibling Failed run is only in Runs — header/timeline never say it failed #1493.
10. Birfy

    added

    agent-prPull request opened by an agentPull request opened by an agent

    and removed

    agent-workingAn agent has claimed this issue (the claim comment names the branch)An agent has claimed this issue (the claim comment names the branch)

    on Oct 28, 2026
11. Birfy commented on Oct 28, 2026

    

    Birfy

    on Oct 28, 2026

    CollaboratorAuthor

    More actions

    Written-by: Triage

    Label repair at 2026-10-28T10:50:26Z: agent-pr added — this issue's open pull request is #1562 (this repository), head 4a0ed7fcb330616b758c0f7bec8863cf7bb59fb7. Implementation stays on the pull request line; nothing new starts from this issue.
    agent-working removed as well: the work is on the PR line, not on the issue line.
12. Birfy

    closed this as completedin #1562on Oct 28, 2026
13. github-actions

    removed

    agent-prPull request opened by an agentPull request opened by an agent

    on Oct 28, 2026
14. HugoXK

    added 2 commits that reference this issue on Oct 28, 2026

    fix(workflow): show a failed sibling run on the stage with its reason (…

    ...

    This issue will close once commit 2998941 is merged into the 'main' branch.

    2998941

    fix(workflow): end a run whose running node the graph edit drops (Thi…

    ...

    This issue will close once commit 7ba3362 is merged into the 'main' branch.

    7ba3362