Hi guys,
The company I work in has signed up for Operations Hub Professional.
I’m running a code snippet within a chatflow (so the code is in Node 14.x). The code snippet calls a custom API, the API gives back the response and this is fed back to the user. This works excellently 80% of the time.
Sometimes though, the API takes longer to respond - above 20s. In these situations, I get the following error in the logs:
2023-06-21T11:59:29.476Z f1d14c1f-c9ff-4762-8302-37680817acc3 Task timed out after 20.02 seconds
Memory: 30/128 MB
Runtime: 20023.10 ms
I’ve tried increasing the timeout for the http API call itself in JS, but it made no difference. This makes me think that possibly it’s the code snippet itself having a timeout?
Thanks!
Hi, @JohnBadanov
To confirm, you are referring to Custom Coded Workflow actions, correct? If so, you are hitting a documented limit. Specifically, it must finish within 20 seconds and can only use up to 128 MB of memory. These are system-wide limits and cannot be changed.
Unfortunately, this means that if your custom API takes longer than 20 seconds to respond, the code action will time out, resulting in the error message you are seeing. Modifying the timeout for your API call wouldn’t change this, as the overall execution of the code action (including waiting for the API response) still needs to fit within that 20-second window.
Best,
Jaycee
Hi @Jaycee_Lewis,
Thanks for the super quick response.
I’m referring to the code snippet functionality in chatflows . This seems to be very similar to the custom coded workflows. Please could you confirm that the same 20s/128MBs limit applies for chatflow code snippets?
It would be great if - when the timeout limit is reached - I had the option of sending a graceful error message back to the user. At the moment, hitting the timeout means that the user is not reading anything, which is not great experience! Is there a way that I can define an error message “Your question wasn’t missed! Our API just took a while to get back. Please try again later.” which the user will see in this exact scenario?
Thanks,
John
@JohnBadanov I have a solution for a ‘graceful’ error message on timeout. What we are doing is as soon as the request is received on our backend, we initiate a timeout timer that expires at 19 seconds. If the timer expires before processing is finished, we send the JSON response:
{'botMessage':"Sorry, we are experiencing network issues. Please try sending your message again shortly.",'responseExpected':True}
This is not ideal. I would rather have a way to indicate to hubspot that we need more time to process the response and extend the 20s code block timeout instead.
@Jaycee_Lewis
I am hitting this same issue. I tried both with a custom code snippet (Node 14) to call our REST api, and with the webhook (in bots) action. It appears the webhook action has the same 20s timeout limitation in Chatflows. Is there any workaround to this?
Is there any way to:
- Customize the Timeout - to be able to set it to 60-90 seconds would be the ideal solution.
- Send a message to the user and then continue waiting for response - For example, “please wait, still processing..” If this can triggered in code at 18-19 seconds before the timeout, and cause the ChatFlow timeout to reset for another 20s, this could be a viable solution.
- Retry the request after timeout - Finally, as a last resort, if we could retry the request after hitting the timeout, it might be a viable workaround. In the workflow API documentation, it’s mentioned that receiving a 429 or 500 response will cause a retry. Is this the case in Chatflow as well? If so, would having the server send a 429 or 500 at 18 seconds (before timeout expires) force a retry of the response if we process the error as documented in the worfklow docs?
Hey, @JohnBadanov @GRuebsamen I took this to my internal resources. I’ll post here when I get a reply.
Best,
Jaycee
Hey, @JohnBadanov @GRuebsamen
I want to close the loop here. After working on this with my internal resources, I was able to get the documentation updated. Conversations | Running Code – Limitations
@JohnBadanov Thanks for bringing this to our attention
@GRuebsamen I do not have a workaround at this time for this limitation
You are both very appreciated. Have fun building! — Jaycee