An interesting fact about default retry policies on logic app connectors is the fact that these default retry policies vary depending on the connector, for example on HTTP connectors, if we use them to send a request to a service, in this example a Logic App, and if that service suffers a Delay, the connection is established for approximately 11 to 12 minutes , where 4 retries are made before abandoning the request, and fail.
But when we use a Logic App connector to do the same task, in this case it still calls another Logic App, the delay it suffers does not matter, at least for a long period of time.
This was the logic app we were calling for both scenarios, and from this specific logic app we expected a response after the delay.
And as you can see in this HTTP request from the main workflow, the logic app failed after 4 retries occurred, and the time it took was 11 minutes.
If we now take a look at the same request made with a Logic App connector, we can see that it lasted the 2 days without failing.
A curious thing is that in both connector settings the same information is present:
A retry policy applies to intermittent failures, characterized as HTTP status codes 408, 429, and 5xx, in addition to any connectivity exceptions. The default is an exponential interval policy set to retry 4 times.
Now we are testing it to a limit of a week, but our gut says it’s going to last without failing.
This difference in behavior between HTTP and Logic App connectors can be beneficial in certain scenarios, as the Logic App connector’s more robust retry mechanism can help handle longer-running or more unreliable services without failing. This can be a valuable consideration when designing integration workflows.
To lazy to read? We’ve got you covered! Check out our video version of this content!
Hope you find this helpful! If you enjoyed the content or found it useful and wish to support our efforts to create more, you can contribute towards purchasing a Star Wars Lego for Sandro’s son!
