Testing & Debugging
Testing & Debugging
Before you rely on a workflow, you want to see it work. Two features help: a step-through debugger that lets you walk a run node by node, and run history that shows what happened during any run. Together they turn “I think this works” into “I watched it work.”
Stepping through a run
The debugger starts a run and pauses it before the first step. From there you can advance one step at a time, or let it run to the end. Each time it pauses, you can see what is about to happen and what just happened.
Start a session
Pick a workflow and start a debug session. The run pauses at the very beginning, before anything has happened.
Step forward
Advance by one step. That step runs, then the session pauses again before the next one, so you can inspect the result.
What you can see at each pause
Debugging runs a workflow for real. Steps that send messages, place calls, or write to other systems will actually do those things while you step through. Use test data, or a workflow set up for testing, if you do not want real effects.
A paused session does not stay open forever. If you leave it idle for a while (about 15 minutes), it ends on its own. Taking any action keeps it going.
Following a run’s progress
Every run, whether you started it by hand or it was triggered, builds up a history as it goes: a timeline of events you can follow in real time. It records when the run started, when each step started and finished, which path a Conditional took, and when the run completed or was cancelled.
This is how you check on a run without stepping through it. You can watch a live run move along, or open a finished run to see everything that happened and in what order. If a step failed, the history shows where.
If a step produces a very large output, its entry in the history is shortened so the timeline stays quick to load. This only affects what the history displays; the full value is still passed on to the next step as normal.