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.