Debugging in the editor

The browser editor has a real debugger. You set breakpoints in your source, start a run, and the worker stops on them — with a call stack, the variables in scope, and stepping.

It is not a simulation. The run happens on the platform, in the same kind of worker a deployment uses, so what you observe is what actually happens.

Starting a session#

Set a breakpoint by clicking the gutter beside a line, then start the debugger from the editor's Debug action in the title bar, or press F5.

A debug run takes the same configuration as an ordinary test run: the payload you supply, the step scope, and the parameter values from the Parameters ▸ Values view. Running and debugging are the same run with the debugger attached — there is no separate configuration to keep in step.

While it is stopped#

You get what you would expect from a debugger:

• Breakpoints, on the lines you wrote — positions are mapped back from the code the platform actually runs, so a breakpoint lands where you put it.
• The call stack, from the paused step outward.
• Stepping — over, into, and out.
• Variables in scope, so this.payload, this.input and this.context can be read at the point of the stop rather than reconstructed from log lines.

Stepping stays inside your code. The platform's own runtime is skipped over, so a Step Over at the end of a step method does not walk into machinery you did not write.

Output#

The bottom panel carries two tabs:

• Debug Console — the debug session's own output.
• Run output — the selected run's log lines, whether that run came from Debug or from an ordinary test run.

That split matters when you are switching between the two: a plain test run's console.log appears under Run output, not in the Debug Console.

What a debug run is#

A debug run is a test run: it executes the draft, and events it emits are recorded but not dispatched, so pausing on a breakpoint cannot hold up production work.

The deployment's limits still apply — most importantly its timeout, which keeps running while you are stopped at a breakpoint. A long debugging session can end as a timed-out run.

When to use it instead of logs#

Reach for the debugger when you need to see state at a moment: what a payload actually contained, what a mapping produced, why a branch went the way it did.

Reach for reading a run when you need to see a sequence: which step failed, how long each took, what was retried. Steps and their recorded results answer that without stopping anything.

Next#

• Testing a flow — fixtures and scoped runs.
• Reading a run — the after-the-fact view.