We've had an issue with our Retool setup related to query retries after timeouts. Specifically, we have an API integrated into Retool that handles client charges, and recently we've experienced instances of double charging where clients were billed twice.
Upon investigating the logs, we noticed that the API calls were made 10 seconds apart, which matches with the default timeout set for this query. so the question is: Does Retool retry queries after they timeout? We've checked the docs but haven't found much on this so far.
Also, what are the best practices to make sure that certain queries are called only once? thanks!
I can't speak to the retry defaults, but a practice I've used to overcome a similar situation is the create an entry in a database at the start of the workflow to log something unique about the call, and check the DB each time to ensure it isn't a duplicate. If you're dealing with a 10 second delay, you could always add a step to the end of your workflow to delete any rows that were created >1 day ago (or whatever makes sense), just to keep the table clean.
Be mindful of race conditions if the calls come too quickly togethers (ie it's writing to the DB while the second call is reading) - it doesn't sound like it will be an issue for you, but worth being mindful of it.
@MikeCB Yes, we're planning to manage these scenarios on the API side. Our plan is to use a unique key for each API request in Redis cache with a timeout, which will automatically delete the key from Redis after the timeout period. However, still want to gain understanding of the retry logic on Retool side.
If the requests are not automatically retried, another possible theory is that the user clicked the "Charge" button after the query timed out. We disable this button and show a loader while the query is running, and then enable it once the query resolves.
However, the user claims to have clicked the button only once, and we don't have any logs to verify this. We are planning to increase the query timeout for now from 10s to 20s. this should reduce the chances of query being timeout.
Are there retries for 5xx class errors? I work with @Neeraj_Gahlot and we're seeing a case where requests that fail are getting retried (and only the second request is coming through to the Retool UI layer) so handing these is proving a bit more interesting.
Hey @shults_duckbill, looks like there are some situations where requests that return a 500 response are retried. I've linked this topic to an internal ticket we have tracking this. I've bumped it internally to get some eyes on it, and I'll update you here when I have any additional information to share.
Hi I just stumbled across this thread and I wanted to post about this behavior but in my case I would prefer automatic retry my issue is opposite are there any options for an autmatic retry of API query which fail wih 500 errors even if they have additionalScopes ?
We are also seeing this behaviour with any our API requests that timeout. The request retries a maximum of twice (three requests made total) - is it possible to disable this behaviour?