Error handling

Failures are part of the graph, not an afterthought. Flowdrome gives you three layers, from node-local to run-global.

Try frames — catch around a section

Try is a frame: drag nodes into it and it becomes an error boundary. Members execute normally; when one throws, it is retried per the frame’s policy, and if it still fails the exception routes out of the frame’s error port — with the error details as data — instead of failing the run. Success flows out of the success port as usual.

Use it like you’d use try/catch: around the flaky HTTP call, the parse that sometimes meets garbage, the third-party API with moods.

The recovery lane — Error Trigger

The Error Trigger starts a recovery phase for the workflow: when a run fails outside any Try frame, the engine executes the error lane rooted at the Error Trigger, handing it the failure context (failed node, error, the run’s data). The main lane and the recovery lane live in the same document — one workflow, its happy path and its incident response.

Typical recovery lanes: notify Slack/Telegram with the error and run id, write the failure to a queue or database, call a fallback API.

Stop and Error — fail on purpose

Stop and Error fails the run immediately with your message and data. Combine it with If/Check to turn business rule violations into first-class failures that Try frames and the recovery lane see — instead of letting bad data limp downstream.

Per-item error policy

When a node runs once per item, its error policy decides what a poison item does: fail the run, or drop the item and count it (surfaced in the node’s run meta). One bad row out of 100,000 doesn’t have to cost you the other 99,999.

After the fact: retry from a node

Every failed run records its envelopes, so the fix-and-retry loop doesn’t start from the trigger: retry from the failing node re-executes only the downstream subgraph, seeded with the recorded inputs. Fix the config, retry from the node, watch it go green.

In deployed apps

All of the above compiles: Try frames, the recovery lane, stop-and-error and per-item policies behave identically in the editor’s engine and in compiled apps. An approval gate’s timeout policy (approve / reject / error on expiry) also feeds the same machinery — an expired gate can deliberately fail the run into its recovery lane.