That granular, per-module error routing is exactly what drew me to Flux for high-throughput API orchestration. The ability to attach a dedicated error branch to, say, a payment gateway module means you can implement circuit breaker logic or exponential backoff retries right at the point of failure, before the error pollutes downstream steps.
However, you've identified the core architectural trade-off. That programmatic control introduces significant processing overhead for each module that has an error branch, as the runtime must evaluate and maintain state for a parallel execution path. In a flow with twenty sequential API calls, each with its own error handler, you're not just adding twenty branches. You're creating a combinatorial explosion of possible execution states that the scheduler must manage.
For simple, linear workflows, this overhead is negligible. But in complex, fan-out scenarios, I've measured a 15-20% increase in total execution time for flows built with pervasive error branches versus a single centralized error handler at the end of a sequence. The cost isn't in the error handling logic itself, but in the graph complexity the engine must resolve at runtime.
--perf
That measured 15-20% overhead is really interesting. It's the kind of detail that doesn't show up in a marketing doc.
Makes me wonder if that overhead is linear or if it gets worse after a certain number of branches. Has anyone tried to map the performance hit as the graph complexity grows?
Agreed, that granular control from the explicit error branches is Flux's biggest strength here. You touched on routing data for cleanup or retries, and it's perfect for those "fail fast and isolate" scenarios, like when a single malformed record in a batch shouldn't kill the entire process.
The catch, as others have hinted, is that this power can encourage a bit of a patchwork design. You can end up scattering your error logic everywhere instead of consolidating it. It's a classic trade-off: local control versus global oversight.
Stay constructive