A workflow has a Resource Query block that calls an API endpoint. The endpoint returns a 500 Internal Server Error. The settings have Finally set to Exit. But the workflow continues to execute all blocks after the error and does not call the global error block.
How do I make an API error (4xx or 5xx) force the workflow to exit and trigger the global error?
This screenshot hopefully shows the API error happen part way through the run, but continue after:
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.
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. 
Hopefully this shows a simple example.
What I observe:
What I want to happen:
I can confirm that the error is NOT caught/handled at the block level (e.g. routed through an On Error connector).
The error handler is looking for blocks that throw an error. In your case, the block is successfully completing with no errors, but returning a code you want treated as an error. The simplest approach I can think of would be to throw in a conditional/branch block that checks API_with_500_error_response.metadata.isError and if >= 400 do one thing and otherwise continue. Another approach would be to add a JS block that forces a “real” error if you just want to automatically send the workflow into your error handler.
Thanks @jg80 , I had thought about this but was really hoping there was a better way. Adding this check in between every single resource block that calls an API in a long workflow is going to be painful. But it works.
I thought that at one point there was a way to have an error response be an error, but I couldn’t find it when I was clicking around for a minute…one thought would be to turn the API call into a workflow function that you call in a JS block and throw in that block directly based on the response. Kind of consolidates a few steps into a single block.
