<@ULVA73B9P> in prefect dashboard, why is it shown...
# ask-marvin
i
@Marvin in prefect dashboard, why is it shown in the runs 70 completed, 2 running but then "No task runs"? The run was interrupted without failing, meaning it was run in debug mode and then abandoned the debug session
m
thought for 193.2 seconds
Yes — that can happen, and in the situation you described it makes sense. What you're seeing - The flow run record exists, so the dashboard can still show aggregate run counts like
70 completed, 2 running
- But the task runs for that specific run may never have been persisted, so the run details page shows “No task runs” Why this happens In Prefect 3.x, flow runs and task runs are not tracked in exactly the same way: - Flow runs are written directly and reliably enough that they usually appear in the UI even if execution is interrupted - Task runs depend on task state transitions being emitted/recorded during execution If you start a run in debug mode and then abandon/interrupt the debug session: - the Python process may stop before task state updates are fully emitted/persisted - the flow run can remain visible in a running/completed-ish state history - but there may be no recorded task run rows for the UI to display So the result is the mismatch: - summary counts show flow activity - task run panel says No task runs Is it expected? Mostly yes — especially for debug-mode/local-interactive execution that is interrupted instead of ending cleanly. It’s less a “the run succeeded” signal and more “the flow run object existed, but task execution metadata was never fully recorded.” Why it looks especially weird Because the run was interrupted without failing, Prefect may not have gotten a clean terminal state for all child task runs. In a normal completion/failure path, you'd expect task runs to show up. Practical takeaway If you want task runs to reliably appear in the dashboard: - let the run exit normally - or let it fail naturally - avoid killing/abandoning the debug session mid-execution If you'd like, I can also help you distinguish whether this was: 1. just an interrupted local debug run, or 2. a broader issue with task run persistence / event processing in your environment.