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

Relationships

#1710 serve dashboard: add instanceId, triggerSource, and step progress to WorkflowRunSummary

Opened by stack72 · 8/18/2026· Shipped 8/18/2026

Problem

We're building a web dashboard for swamp serve (served at /dashboard behind a --dashboard opt-in flag). The API surface audit revealed three schema-level gaps in WorkflowRunSummary that block the dashboard's core panels. Without these fields, the dashboard cannot show per-instance breakdown, trigger source badges, step progress counts, or failure details without expensive N+1 queries.

Proposed Changes

1. Add instanceId to WorkflowRunSummary & WorkflowRun (P1 — Blocker)

Record which serve instance executed the run at start time. This is the single most impactful change — it enables:

  • Per-instance filtering of all historical run data
  • Per-instance breakdown in KPI tiles (runs, success rate, throughput)
  • Instance scope toggle on the dashboard (show one instance vs cluster-wide)
  • The executions table showing which instance ran each workflow

Files: src/domain/workflows/workflow_run_summary.ts, src/domain/workflows/workflow_run.ts

The RunTracker already has instanceId but it only tracks in-flight/recent runs. The WorkflowRunSummary (which powers workflow.run.search and workflow.history.search) does not carry it. The field should be set when the run starts executing on a serve instance.

2. Add triggerSource to WorkflowRunSummary (P1 — Blocker)

Add a field indicating how the run was triggered: "schedule" | "webhook" | "api" | "manual".

Currently this information exists only in telemetry (triggerSource field in src/serve/telemetry.ts) but is not persisted on the run record. The dashboard needs it for:

  • Trigger badges on every execution row (schedule/webhook/manual)
  • Filtering executions by trigger type
  • The live runs panel showing how each run was initiated

Files: src/domain/workflows/workflow_run_summary.ts, src/serve/telemetry.ts (the source of the value), workflow run creation paths in src/libswamp/workflows/

3. Add failedStep, failureReason, and stepProgress to WorkflowRunSummary (P2 — Important)

Three additional fields to avoid N+1 queries:

  • failedStep: string | undefined — name of the first step that failed
  • failureReason: string | undefined — error message from the failed step
  • stepProgress: { completed: number; total: number } | undefined — steps completed vs total

Without these, the dashboard's "Recent Failures" panel requires loading the full WorkflowRun aggregate for every failed run to get the step name and error. The executions table needs full run records to show "4/12" progress.

Files: src/domain/workflows/workflow_run_summary.ts, src/libswamp/workflows/ (the run summary builder)

Context

This is part of the swamp serve dashboard initiative. The full gap analysis covers 22 dashboard data needs mapped against the current API surface. These three schema changes are the foundation — they unblock the Overview, Executions, and System views. The remaining gaps (cluster.instances endpoint, serve.config endpoint, health snapshot enrichment, worker.list enrichment) can be addressed in follow-up issues.

Dashboard mockup and full gap analysis available as artifacts from the competitive analysis session.

02Bog Flow
OPENTRIAGEDIN PROGRESSSHIPPED+ 1 MOREASSIGNED+ 5 MOREREVIEW+ 4 MOREPR_MERGED+ 2 MORESESSION_SUMMARIZED

Shipped

8/18/2026, 10:38:31 PM

Click a lifecycle step above to view its details.

03Sludge Pulse
stack72 assigned stack728/18/2026, 6:42:45 PM

Sign in to post a ripple.