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

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.