Skip to main content

THE RUN TRACKER

Models and workflows produce data, but that data only appears after an execution finishes. While a method is running — or while a workflow is waiting on a dependency — there was no way to answer a basic question: what is executing right now? swamp model method history shows completed runs. Audit shows issued commands. Neither tracks in-flight work.

The run tracker fills this gap. Every model method execution and every workflow run registers with a local SQLite database (.swamp/run_tracker.db). Each registered run heartbeats every 30 seconds. If a heartbeat stops and the originating process is no longer alive, the run is considered stale and eligible for reaping. swamp run history lists recent and in-flight runs; swamp run doctor identifies and optionally clears stale ones.

The tracker uses SQLite rather than the shared datastore because run tracking is inherently local. A tracked run records a PID — a process ID that is meaningful only on the machine where the process is executing. PID 12345 on machine A is a different process than PID 12345 on machine B. Sharing this data across machines would create false signals. For remote visibility, swamp run history --server queries the server's own local tracker over WebSocket, keeping the data authoritative for each machine.

Runs are retained for 7 days and pruned automatically. The tracker is an operational tool — a window into what is happening right now — not an audit log or a durable record. The audit system, model method history, and workflow history serve those longer-lived needs.

← PreviousData LifetimesNext →Configuration Layers