Summary
A workflow's Resource Query block calls an API that returns a 500 error, but despite the block's 'Finally' setting being used, the workflow keeps executing downstream blocks and never triggers the global error handler. The question is how to make a 4xx/5xx API error force the workflow to exit and fire the global error block.
AI Response
This is expected behavior: per Retool's documentation, workflows continue to run even after an error triggers a global error handler, and the global handler only fires for a block that fails without an On Error connection. First, confirm the Resource Query is actually throwing — if 'Finally' is set so the error is caught/handled at the block level (e.g. routed through an On Error connector), the global handler is suppressed and the run proceeds. To stop execution, let the block fail unhandled (so nothing downstream is wired to run after it) and place terminal logic in the global error handler or a Response block that returns a non-200 status using workflowContext.currentRun.error; note that remaining blocks are not automatically aborted, so downstream branches should be gated so they don't run once the error path is taken.
Sources
Configure workflow error handlers | Retool Docs
Official guide explaining block-level vs. global error handling, including that global handlers only run when a block fails without an On Error connection and that workflows continue running even after an error is triggered.
Errors should break the flow
A solved community topic reporting the same expectation—an unhandled block error should break the chain—and discussing how error propagation and termination actually behave in workflows.
The Community Team is testing out a new automation. Let us know if it's helpful (or not) by leaving a
,
, or
. Or by marking this post as the "Solution"! Let us know if you have any feedback here. ![]()