Skip to content
threadle threadle

Errors & retries

Agent runs are flaky in ways pure code is not — a CLI hiccups, a model returns nothing, a tool call times out. threadle gives every node its own failure policy.

Default behavior

Section titled “Default behavior”

A node that throws marks itself error and stops the run. Nodes already finished keep their results; queued nodes never start.

That’s the right default for a pipeline where step three depends on step two being correct.

Retry

Section titled “Retry”

Right-click a node → retry: off, 1×, or 3×.

Retries use a short backoff between attempts, and each attempt is logged:

⟳ implement failed (attempt 1/4) — retrying: CLI exited 1

Retry is worth it for transient failures (network, rate limits) and pointless for deterministic ones (a bad model name, an unwired input).

Continue on error

Section titled “Continue on error”

Right-click a node → continue on error. On final failure the node goes red, the run keeps going, and anything downstream of it starves — those nodes are skipped because their input never arrived.

⤼ review failed after 2 attempts — continuing: …
∅ output starved (upstream muted/failed) — skipped

Use it for optional branches: a nice-to-have summary that shouldn’t sink the run that produced the actual work.

Starvation is not failure

Section titled “Starvation is not failure”

A starved node is idle, not errored. threadle distinguishes:

StateMeaning
errorThis node ran and failed
idle (starved)This node never ran — its inputs never arrived
idle (muted)You told it to skip

This matters when reading a run log: a wall of skipped nodes usually has exactly one red node at its head.

The retries tripwire

Section titled “The retries tripwire”

Per-node policy handles individual nodes. The retries tripwire mode watches the run: it trips once the accumulated failure count crosses a threshold.

“Tolerate two flaky steps, abort on the third” is a single node.

Interrupted runs

Section titled “Interrupted runs”

Stopping a run (or closing a canvas run) leaves no node stuck glowing: anything still queued or running is reset to idle when the run ends. Detached runs survive the browser entirely — see Detached runs.

Where failures are recorded

Section titled “Where failures are recorded”
  • Run log — full per-node detail, including stderr excerpts from custom nodes
  • Runs view — one row per run with status and error
  • The node itself — status persists on the graph after a detached run, so you can open it later and see what went red
Section titled “Related”