Summary
There is no read-only way to see which background workflows are running. The only command that lists them is conductor stop — which stops one when exactly one is running:
With no arguments, lists running background workflows. If exactly one is found, stops it automatically.
So the natural "what's running?" reflex is destructive precisely when there is a single run to lose. I killed a healthy 40-minute workflow this way: I ran conductor stop to check status, having read the help text as "lists, and if unambiguous, offers to stop". The behaviour is documented, so this is not a correctness bug — but the documentation is the only thing standing between the user and data loss, and the destructive path is the shortest one to type.
The asymmetry is what makes it sting: with two runs it prints a table and does nothing, with one it terminates. The safe outcome is the one that requires more runs to be active.
Why a flag on stop isn't the fix
conductor stop --dry-run would work mechanically, but it keeps the hazard one typo away and leaves "list running workflows" filed under a destructive verb. Discovery is a read operation and wants a read verb.
Proposal
Add a read-only listing command — conductor status (or ls / ps):
conductor status
conductor status --json
It already exists in pieces: read_pid_files() (cli/pid.py) does the discovery and stale-file cleanup, and _print_running_list() (cli/app.py) does the rendering. This is mostly wiring them to a command that doesn't kill anything.
Worth surfacing per run, all of which are already in the PID file or one probe away:
- port, PID, workflow name, start time (all present today)
- the dashboard URL, so it can be pasted straight into a browser — this is the field I actually want most often, and there is currently no way to recover it after the launching terminal is gone
- liveness, and whether the dashboard is answering
--json for the same reason stop needs it: automation should not have to parse a table.
Then narrow stop
Once discovery has its own home, bare conductor stop auto-stopping a single run is defensible as a convenience — but I would still argue for requiring --port or --all to name a target explicitly, since "stop" reading as "show me what's running" is exactly the misreading that costs a run. At minimum, printing what it is about to stop and why would make the destructive step legible.
Related
Summary
There is no read-only way to see which background workflows are running. The only command that lists them is
conductor stop— which stops one when exactly one is running:So the natural "what's running?" reflex is destructive precisely when there is a single run to lose. I killed a healthy 40-minute workflow this way: I ran
conductor stopto check status, having read the help text as "lists, and if unambiguous, offers to stop". The behaviour is documented, so this is not a correctness bug — but the documentation is the only thing standing between the user and data loss, and the destructive path is the shortest one to type.The asymmetry is what makes it sting: with two runs it prints a table and does nothing, with one it terminates. The safe outcome is the one that requires more runs to be active.
Why a flag on
stopisn't the fixconductor stop --dry-runwould work mechanically, but it keeps the hazard one typo away and leaves "list running workflows" filed under a destructive verb. Discovery is a read operation and wants a read verb.Proposal
Add a read-only listing command —
conductor status(orls/ps):It already exists in pieces:
read_pid_files()(cli/pid.py) does the discovery and stale-file cleanup, and_print_running_list()(cli/app.py) does the rendering. This is mostly wiring them to a command that doesn't kill anything.Worth surfacing per run, all of which are already in the PID file or one probe away:
--jsonfor the same reasonstopneeds it: automation should not have to parse a table.Then narrow
stopOnce discovery has its own home, bare
conductor stopauto-stopping a single run is defensible as a convenience — but I would still argue for requiring--portor--allto name a target explicitly, since "stop" reading as "show me what's running" is exactly the misreading that costs a run. At minimum, printing what it is about to stop and why would make the destructive step legible.Related
conductor stopconfirm the process actually stopped #383 —conductor stopcould delete the PID file without stopping the process. Once that lands, a run can survivestopand stay registered, which makes a read-only listing more valuable: it becomes the way you find the survivor. fix(cli): makeconductor stopconfirm the process actually stopped #383 adds--jsontostop;status --jsonwould be its natural read-only counterpart and could share the payload shape.