Skip to content
Fluxify

error handling Failures go where you wired them.

A backend is mostly what happens when things go wrong. In Fluxify every failure has a visible destination on the canvas — and a broken save never reaches your users.

Read the docs
throws → jump Entrypoint GET /orders/:id DB Get Single connection refused Response 200 · never reached Error Handler one per canvas Response 500 · clean body
The Error Handler has no input socket. It compiles to the catch around the whole route, so a throw anywhere — inside loops and branches too — lands there.

two kinds of no

An expected “no” is a branch. A failure is a jump.

“User not found” isn't an error — it's a path. Use a failure socket for it, and keep the Error Handler for things that genuinely broke.

failure socket

Expected outcomes

If Condition, DB Row Exists and Send Message have a failure socket. Wire it to a 404, a 401, a fallback — it's ordinary control flow.

error handler

Real failures

A refused connection, a bad query, a thrown JS error. The run jumps to the Error Handler with the message. Without one, the route answers 500 with the error.

transactions

All of it, or none of it.

Put several database writes on a DB Transaction's executor socket. They commit together — or a Rollback block, an error or the timeout undoes every one and the failure path runs with the reason.

one transaction · executor chain executor commit rollback · error · timeout DB Transaction serializable · 30s DB Update stock: { op: 'dec' } DB Insert orders Response 201 success Response 409 failure · { reason }
Commit → success with the chain's last output. Rollback block, error or timeout → everything is undone and failure runs with { reason, message }. Deadlocks and serialization failures can be retried.

retries

Try again, then give up cleanly.

Wrap a flaky call in a Retry block. It re-runs its executor chain when it throws, waiting longer each time, and hands either the result or the attempt count to the next block.

time → wait 250 ms wait 500 ms wait 1 s try 1 ✕ try 2 ✕ try 3 ✕ try 4 ✓ success retryType: exponential · delayMs: 250 · maxDelayMs: 5000 · maxRetries: 3
Fixed, linear, exponential or exponential with jitter. Each wait is capped by maxDelayMs; when every try fails, failure receives { attempts, message }. Retrying a write can run it twice — make it safe to repeat.

deploys fail closed

A broken save never ships.

If a flow can't compile — a missing setting, a cycle — the version that's already serving keeps serving, and the error is shown in the editor. Workflows that fail are retried; queue triggers can dead-letter messages that keep failing.

v1 serving traffic still v1 save v2 → compile ✕ missing setting · rejected error shown in the editor
next Logic & data flow Branches, switches, loops, parallel calls, and data on the wires.