Custom Retry policy for the HTTP connector
Is it possible to have a fine-grained control on retry policies for the HTTP connector to distinguished the use cases related to HTTP errors.
For example: having a different policy for HTTP 500 error and another retry policy for HTTP error 429, ...
The built-in retry policy won’t retry non-retry-able errors. Since there are many scenarios where users need to interrogate the content to determine how it should retry we thought it be better to keep the retry policies simple and allow users to utilize the do-until loop for more custom retry decision logic.