Skip to main content
← Back to list
01Issue
BugShippedSwamp CLIPublic
Assigneesstack72

Relationships

#3005 dashboard: approved autoResume run shows Resume and needs-inputs hint while serve already resumed it (status running)

Opened by randybias · 10/4/2026· Shipped 10/5/2026

Summary

The dashboard Overview "Live Runs" card offers Resume for an approved run of a workflow with autoResume: true. Serve has already auto-resumed that run, and it is running. Clicking Resume fails with "not suspended or failed (status: running)". The card also shows the needs-inputs hint ("This workflow declares inputs. Resuming here supplies no new inputs...") and a --input <key>=<value> command. Neither applies, because serve resumes the run itself.

Versions

serve image docker.io/swampclub/swamp:20260929.002922.0-sha.55e2ef29; serve flags --remote-only, auto-resume: true, approve-requires-explicit-grant: true. The workflow is placed (labels: {pool: colo-ops}), sets autoResume: true, and declares inputs.

Observed (2026-10-04, UTC)

  • Run 01439df3-2649-435a-93f2-7f374929fae8, started 08:41:14Z, has one manual_approval gate (step approve-release), approved through serve.
  • After the approval, the Overview card showed: "Approved — awaiting resume" [Resume]. It also showed the needs-inputs hint and swamp workflow resume mircloud-rollout-webapp --run 01439df3-... --input <key>=<value>.
  • Clicking Resume returned: "Run 01439df3-... is not suspended or failed (status: running). Wait for it to complete, or check progress with 'swamp workflow history mircloud-rollout-webapp'."
  • swamp workflow history get 01439df3-... --json (through serve) shows status: succeeded at 08:43:07Z. Every step after the gate (apply, check, verify) succeeded. Serve's auto-resume worked; only the dashboard state was wrong.

Source (main at bed0772a)

  • packages/dashboard/src/client/resume_state.ts:44 resumeStateFor returns a resume state when run.status === "suspended" && run.awaitingResume. It ignores the workflow's autoResume and serve's auto-resume, so a run that serve resumes itself is still offered for a manual resume.
  • The card renders from the run-search row. The row still said suspended + awaitingResume after serve had started the resume, so the row and the run disagreed. That points to a stale run-search row, or a race between approval and auto-resume.

Expected

  1. For a run that serve auto-resumes, show "Approved — resuming" (no Resume button, no needs-inputs hint), or hide the action.
  2. The Live Runs row reflects running as soon as serve starts the resume.

Impact

Cosmetic but misleading. It invites an Operator to resume, and to supply inputs to, a run that is already running. The server refuses the resume, so state is safe.

02Bog Flow
✓OPEN✓TRIAGED✓IN PROGRESS✓SHIPPED+ 1 MOREASSIGNED+ 5 MOREREVIEW+ 10 MOREPR_MERGED+ 2 MORESESSION_SUMMARIZED

Shipped

10/5/2026, 3:28:17 PM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack7210/5/2026, 2:44:56 PM
Editable. Press Enter to edit.

stack72 commented 10/5/2026, 3:28:21 PM

Thanks @randybias for reporting this! We shipped: Make the dashboard treat a run that serve is actively driving (listed in the health stream's activeRuns) as being resumed: no Resume button, needs-inputs hint or --input command, whoever made the approval. Refetch run search when that active-run set changes, or while an active run's row still reads suspended, so the row moves to running and then finished. Applies to every view that renders ResumeAction: Overview Live Runs, Approvals' Awaiting resume panel, and run detail.. The fix has been merged and a release is on its way. We appreciate your contribution to swamp.

Sign in to post a ripple.