Monitoring

The status bar along the bottom of the window is where the client reports what is happening — your connection state, the latest server message, and any errors or warnings that have come in.

Reading the Status Bar

From left to right:

1. Connection indicator — a coloured dot plus a label: Disconnected (red), Connecting… (yellow), or Connected (green).

2. Current message — the most recent message from the server. Long messages are truncated with an ellipsis.

3. Last statuses button — only visible when there are pending messages. It summarises them as “N error(s), M warning(s)” and is coloured to match the worst severity: red for errors, yellow for warnings, neutral otherwise. Click it to see the full list.

4. Dismiss (✕) button — clears all pending status messages.

The Last Statuses Window

Clicking the summary button opens a floating window titled Last Statuses. It lists every message the server has sent this session, newest first, with its severity, timestamp, and full text.

The window stays open until you close it manually — it does not close when you click elsewhere — so you can leave it open while you investigate. Its size and position are remembered.

Note

Last Statuses is global, read-only, and extension-agnostic: it shows whatever the server reports across the whole session, exactly as the server phrased it, and there is no “jump to node” or similar affordance on its rows. For compile-time problems with a specific task’s graph — clickable issues that locate the node or port they refer to — use the task Editor instead.

Reading a Runtime Status

A status the engine emits during a run answers three questions, in this order.

Which Task. Where a message needs to say, it names the Task — Task {task}: the path from {trigger} stopped …. Statuses from different Tasks share one window, so this is the first thing to read.

Which Node. A message that concerns a particular Node carries its address rather than a bare number, and whoever shows you the message resolves it. Here, in a plain list, you read it as words: node index 2, or node index 2 input 1 when the message is about one port.

An index is not the number on the Node

A Node carries three different numbers and only one of them appears here. The index is its position in the Task, counted from 0; the id is what the Editor labels it with; the step number is what the Editor prints once you pick a Trigger. They routinely differ. Error Handling explains which is which — check there before counting Nodes on the canvas.

Which port. input 1 counts that Node’s Inputs from 0, in the order the Node declares them — the same order the Node tab lists them in.

Then read the severity, which is what separates a Path that stopped on purpose from one that failed: the message text alone often will not tell you. To work back from a status to a cause, use When a Path Stops.

Status Level: what each level lets through

How much a Task reports is a per-Task setting called Status Level, on the Task itself rather than on any Node — there is no per-Operation override. It records every status of the level you choose or more severe, so each row below adds to the ones above it.

Status Level	What it adds	Practical effect
None (default)	nothing	Silent, except a Task’s own retirement, which always shows (see below).
Critical	the engine’s own failures	Effectively silent for graph problems.
Error	an Operation that could not finish, a value type a Node cannot read	Real failures, nothing else.
Warning	nothing new	Same as Error.
Information	a rule that is not satisfied, deliberate stops, closed Gates	A Gate closing and a Node standing down become visible.
Debug	an On Error verb that continued	On Error: continued with the last value and On Error: continued with the fallback (output {} = {}) become visible as they fire.
Trace	everything the engine emits	Diagnostic only.

Retirement itself is never gated. The engine retiring a Task — for a runaway firing (a firing-rate or firing-depth cap crossed) or for a failure it catches during construction or a run — is recorded at every Status Level, including None: the report is unconditional, not filtered by the level you have chosen.

None is the default: a Task says nothing unless asked. Raise it to see stops, resolved failures, or to debug — Information shows a closed Gate or a rule that is not satisfied, Debug shows a verb that quietly resolved a failure, and Trace shows everything else the engine emits.

Debug is the level to diagnose at — the first level at which you can see a verb resolve a failure.

What it costs: every recorded status is a message on the wire and a row in this window. A Task firing at any rate fills the window quickly at Debug and faster at Trace. Raise it while you investigate and lower it afterwards; a Task left at Trace is noise that hides the next real problem.

Clearing Messages

Messages stay until you dismiss them. Two ways:

• ✕ in the status bar — clears all at once.
• Closing and reopening the client does not clear them; they live as long as the server keeps the session state.

If a message is informational (“task saved”, “operation completed”), dismissing is fine. If it’s an error or warning, read the full text in the Last Statuses window before clearing.