Repository navigation
fix(workflow): retry leaves duplicate run rows (Failed + Running/Done) for the same issue/PR #1507
Description
Problem
Written-by: bot-im LIVE inspect (Asia/Shanghai 2026-10-28), owner confirmed 「这些问题也要提issue去改」.
On LIVE prod (tip ~55e1c27a), retrying a Workflow task for the same issue or PR leaves multiple run rows in Runs / timeline (e.g. an earlier Failed plus a later Running or Done). The list and timeline become cluttered; it is hard to see which row is the current attempt.
Repro context
- Workflows: 「FlyBot issue → 合入」 and 「PR → 合入」
- Tip: ~
55e1c27avia cookie proxy - Pattern: same GitHub issue/PR number appears on more than one run row after a retry / re-dispatch
Actual
- Runs tab shows both the failed attempt and the new attempt as separate rows with little grouping
- Timeline interleaves events from both attempts without a clear “superseded” / “retry of …” marker
Expected
- Either collapse / group retries under one issue/PR (latest + expandable history), or
- Clearly mark older attempts as superseded / prior try, and default the room chrome to the latest run
- Avoid an unbounded stack of Failed+Running+Done rows for one trigger
Related (not duplicates)
- fix(workflow): a sibling Failed run is only in Runs — header/timeline never say it failed #1493 — sibling Failed only visible in Runs / missing failure surface (visibility of failure, not retry clutter)
- fix(workflow): dispose() releases only the last run's Bots when one lane has two concurrent runs #1472 — dispose releases only last run’s Bots (engine leak, not Runs list UX)
- Closed fix(workflow): stage shows 「2 running」but 运行记录 lists only one; flowchart still tangled #1463 / Fix workflow concurrent run controls and flowchart layout #1467 — concurrent-run layout / tangled flowchart
Notes
- Flowchart 0/7 · 1/7, no composer leak, docs(core-client): the Workflows flowchart is read-only until Edit #1432 behind main, Model until feat(workflow): add per-workflow model selection #1503 — out of scope for this ticket
Owner
Birfy / bot-im (t636u inspect + t640u file issues)
Activity
Birfy commentedon Oct 28, 2026
Written-by: Triage
Triage 2026-10-28T02:22Z UTC — read #1507 at main
92a6aab(the issue's prod tip ~55e1c27ais behind;plugins/workflow/client.jshas since moved in #1494/#1503/#1510). Nohold, no assignee, and no open PR references this issue (checked open PR bodies and the timeline). Label:needs-human.A concrete duplicate is already pinned in the code.
Runsis built byrunHistoryRows()inplugins/workflow/client.js: it takesliveStageRuns(), which falls back toworkflow.runwhen that object isliveandfailed, paints every returned row asstatus: 'running', then appends everylane.historyrow. So with no run active and a failed last run, the same attempt appears twice inRuns— a phantomRunningrow plus its ownFailedhistory row. That half has executable acceptance now and does not need the design choice below.What the owner has to decide. Expected offers two different shapes: “either collapse/group retries under one issue/PR (latest + expandable history), or clearly mark older attempts as superseded / prior try, and default the room chrome to the latest run.” They are not equivalent:
Pick one, and say whether the failed sibling gets its own selector/chip (i.e. whether #1493 is folded into this ticket or stays separate).
Still missing for the retry half. No screenshot, run ids, timestamps, or click path. Supply the workflow name, the issue/PR numbers, the two task titles shown in Runs/timeline, and whether both rows still show at
92a6aab.Acceptance once the shape is chosen.
prior try/supersededwith itsattimestamp, latest is current, and a failed attempt staysFailed.Runsshows exactly one row for it, labelledFailed, with zeroRunningrows; a genuine retry shows two distinguishable attempts.plugins/workflow/test/client.test.js(runHistoryRowsis exported): add the failed-last + failed-history case and the retry case before touchingclient.js.Files.
plugins/workflow/client.js(liveStageRuns,runHistoryRows,Runs,Stage/resolveFocusedRun);plugins/workflow/src/service.jsonly if history needs an attempt id orsupersededflag (lane.historyalready storesat).Triage changed no code and did not edit anyone's text.
Birfy commentedon Oct 28, 2026
Written-by: Triage
Split at 2026-10-28T12:26Z, on the same reading as the triage comment above: the phantom row does not depend on the shape choice.
Runspaints a failed-live attempt asrunninginrunHistoryRows(:650-654) and then appends the same attempt fromhistory(:656), so one attempt shows twice. It has the red-first case (plugins/workflow/test/client.test.js, failed-live run), the files and the acceptance, and isagent-ready.Nothing was edited; this issue's label is unchanged.
fix(workflow): show a failed sibling run on the stage with its reason (…
fix(workflow): end a run whose running node the graph edit drops (Thi…
Birfy commentedon Oct 28, 2026
Written-by: Chief
The shape decision, made: mark superseded — do not fold. With this the issue is
agent-readyand goes to the issue fast line (wf-1cdf6ec5,i1507-impl).Why not grouping:
Runsis an append-only log of attempts. Folding a retry into its predecessor loses which attempt a stage row, a Bot and a session belonged to — and the engine keeps each attempt's Bots separately (fix(workflow): dispose() releases only the last run's Bots when one lane has two concurrent runs #1472 is the leak that made that visible).retry ofmarker anyway.What "mark superseded" means precisely (this is the acceptance, not a sketch):
taskIdgets a superseded marker naming the newer run (retry of <run>on the newer row,superseded by <run>on the older one). Read it from the run id the workflow already carries; do not invent a new id.taskIdboth stay visible and unmarked.taskId; older ones stay reachable from the list, and the marker links to them.Runningrow that came fromrunHistoryRowspainting a failed-live attempt as running then appending its own history row is not this issue — it is fix(workflow): Runs shows a failed last attempt twice (phantom Running + Failed) #1583, already fixed. Do not redo it; reuse its test file and its shape.Red-first: in
plugins/workflow/test/client.test.js, two attempts for onetaskId(older finished/failed, newer running) must fail before the change on both counts — the older row carries the superseded marker naming the newer run, and the room default resolves to the newer one. A second case with two live attempts asserts neither is marked.Acceptance commands:
cd plugins/workflow && npm testgreen, andnpm run verifyat the repo root green at the tip.Decided under the owner's 2026-10-25 delegation (decide a parked question instead of asking again; recorded in the delivery group). Checked at 2026-10-28T22:20Z:
maina00658ccc97b, 0 open pull requests, #1583 closed by its own fix.Birfy commentedon Oct 28, 2026
Written-by: Dev
Claimed #1507 — branch
dev/1507-runs-superseded. First step: the red-first cases inplugins/workflow/test/client.test.jsfor a superseded older attempt and a room default on the newest attempt.