We are encountering an ECONNRESET (Connection Reset) error while executing a Retool Workflow that calls the Braze API. We need help determining whether this is a Retool configuration issue, a networking problem, or if the Braze API is abruptly closing the connection.
Campaign Goal: Send an email that includes an attachment.
Execution Logic: The Workflow iterates and sends a batch of 100 objects per API call, with a 1-minute delay (throttling) between each query execution.
2. Error Received
During the last execution, the Workflow failed, and the exact error logged was:
Error: FetchError: request to https://electromaps.retool.com/api/workflow/runQueryForSandboxed failed, reason: read ECONNRESET
3. Key Questions and Diagnostics
Braze vs. Retool? Is it common for Retool Workflows to encounter ECONNRESET when handling throttling or large batches with external APIs?
Braze Dashboard: Checking the Braze dashboard, the API failure rate is 0%, suggesting that Braze is not logging a clean HTTP error, but the connection is being severed prematurely.
Any guidance on managing the throttling logic or whether adjusting the query timeout in Retool might help would be greatly appreciated.
Hi @Lucia_Gomez, this could have something to do with the workflow timing out (on the Retool end). I've tried searching in our logs for an ECONNRESET but our logs may be different than what you're seeing.
If you'd like to send me a specific Workflow Run Id on a run that you are hitting this error, then it would help us dig into this further!
** Starting run for workflow: dd820ca5-f3f3-4913-b45a-82ef9d7e450d in environment production** Wed 2025-12-03 15:03:25 Workflow Run Id: 019ae486-653b-7436-b624-a0653329cf8f
I’m receiving the error when running an API Call on this next code:
Thanks for the extra info! I was able to see some eventual 400 and 429 status codes (Bad Request and Too Many Requests) associated with that run, but I can't see what resource is hitting the rate limit.
I know you mentioned that Braze is not seeing an error, but on their API page for that url they mention having a limit of 50 external ids per batch request. Otherwise they have a 250 request per minute limit.
Retool DB has a rate limit of 1000 requests per minute. You can see your resource usage like so: https://electromaps.retool.com/audit. (To anyone else reading this you can do the same from https://your-org-domain.retool.com/audit).
Based on this I think it could be worth trying smaller batches and seeing if that fixes it!
Thanks for your help. For the last six months, I’ve been processing batches of 200 without any issues. However, our invoice volume nearly doubled in December, and that’s when I started encountering this error.
I’ve already tried reducing the batch size to 100, and then even down to 50 users, but the error persists. I will try less than 50 users. My current workflow includes a 1-minute delay between batches.
Given these details, do you have any other suggestions or perhaps a specific rate limit recommendation I should follow?
@Mike_M the braze team is asking for:
"please provide an example 429 log(s), the corresponding request body where you are getting the 429 response, alongside the exact timestamp (please let me know the timezone of timestamp)"
I will send them the request body, but can I ask you for the logs?
Thanks!
I think because those functions are being triggered from within a js block in your workflow (rather than the queries being blocks themselves) we are missing a lot of context on what resources are erroring out in your workflow. So it's possible these weren't from Braze, especially if they aren't seeing errors and its been working for 6 months. The logs don't have much except metadata but the timestamp of one of the 429 errors is dec 3, 2:55 pm UTC or 1764770635000 as a unix timestamp.
We've been looking at your processArray function and there really isn't anything that stands out for hitting a rate limit. Just to be clear, from your end are you seeing it fail at this step?
Hi Mike! I’ve updated the process and tried sending the 956 emails in batches of 50. The good news is the old error is gone, but now two new ones have popped up.
I’m attaching the screenshots here—any idea why this is happening?
Hi Lucia, I was taking a look at this and was thinking that the issue might be due to the structure of this part of the workflow. One of the reasons I wanted to see the app export was that I was curious about the functions you were triggering and how they were set up. Now that I see the workflow, I believe using a js block to trigger unconnected blocks (getAmazon, reeplaceSignedURL, llamadaBraze, etc) is likely what is causing these errors. For example, I could imagine that the original error was from one of those blocks timing out, and these two new ones are specifically saying "internal error running a block". Despite the fact that you can trigger blocks this way, it's my impression that workflows aren't necessarily designed to run this way, and so they are breaking under the increased payload.
We recommend refactoring these unconnected blocks into functions, which is a more expected and supported way to organize your workflow. Let us know if that solves the issue!