Relationships
#2377 dashboard: an approved run never resumes and the dashboard cannot resume it (workflow.resume is never called)
Opened by randybias · 9/22/2026· Shipped 9/23/2026
Problem
A run approved in the dashboard never continues, and the dashboard gives no way to continue it. Approving is a record edit; resuming is an execution that needs a driver; nothing in serve connects the two.
Traced in 20260922.011324.0:
workflowApprove(src/libswamp/workflows/approve.ts) marks the gate step succeeded in the run record and returns. The serve handler (workflow_handlers.ts:1005) then callspushChangedToRemote. Nothing else.- The only callers of the approve path are the WebSocket handler and the CLI. No scheduler, reconciler or subscriber reacts to an approval.
--reconciliation-intervalis peer reconciliation, not suspended runs. handleWorkflowResumebuilds run deps, an ephemeral store and step locks and streams the run, so resume is a client-initiated execution. When the run suspended, the executor persisted its checkpoint and returned, and the client that started it exited.- The dashboard bundle calls
workflow.approve,workflow.rejectandworkflow.approvals, and neverworkflow.resume, although serve exposes it. Checked against the served asset/dashboard/assets/index-B6vcd3ZC.js.
Measured, end to end
| Time (UTC) | Event |
|---|---|
| 21:46:45 | workflow.run by user:rbias, suspends at the gate |
| 22:01:17 | workflow.approve by user:rbias, in the dashboard |
| 22:01:23 – 22:05:41 | run stays suspended; nothing runs |
| 22:05:58 | workflow.resume from a terminal; the run completes in 17.8 s |
An operator who only has the dashboard is stuck at step 3, with no indication that anything is required of them.
Ask
- A Resume action in the dashboard, next to Approve on a suspended run. Serve already supports it, including the detached form where serve drives the run itself (
activeRunRegistry,kind: "workflow-resume"), so a dashboard resume need not hold a socket. - An opt-in auto-resume for the common case: when every gate on a run is decided and the workflow declares no resume-time inputs, serve continues it. Per workflow (
autoResume: true) or per server (--auto-resume). Off by default, sincedesign/primitives/workflows.mddocuments resume inputs as the reason the two are separate — that pattern must keep working. - Failing either, say so in the dashboard: an approved run that still needs a resume should show the exact command.
Why it matters
Gated workflows are how a human authorises a production change. If clearing the gate requires the approver to then find a terminal, the dashboard is not a complete approval surface, and an approved change can sit unexecuted with nobody aware of it.
Shipped
Click a lifecycle step above to view its details.
stack72 commented 9/23/2026, 11:54:52 AM
Thanks @randybias for reporting this! We shipped: Close the approve-to-resume gap in serve two ways. (1) The dashboard can resume an approved run: a detached workflow.resume call, a Resume action on runs awaiting resume, and the exact CLI command shown as a fallback, with an --input placeholder for workflows that declare inputs. (2) An opt-in auto-resume: a workflow field autoResume, plus a serve flag --auto-resume (default off) that applies only to workflows declaring no inputs; the workflow setting always wins. When every gate on a run is decided through serve, serve launches a detached resume itself, using the canonical run identity and charged to the approver. The detached-resume block in handleWorkflowResume is extracted into a shared launcher, so the manual and automatic paths share one implementation. Also fixes the dashboard approving without a runId and leaving stale approval cards.. The fix has been merged and a release is on its way. We appreciate your contribution to swamp.
Sign in to post a ripple.