Retry wrapped around hystrix call?

[ybbus]

Hi.

Does it really make sense, that the http retry mechanism is outside the CB call?

For me this seems very unintuitive:

When the CB is open, there will still be retries and also time.Sleep() backoffs. Isn't the intent of an opened CB also for the calling system to get a fast feedback and don't waste time?

Even on a completely new request there is no check if the cb is currently open. Why would one do retries and spend time waiting on an open CB?

For me it would make more sense to do the retries inside the cb. So you define the following behavior:

• remote systems may fail, but the CB should only count a failure after the retries did not help
• if the remote system fails and the cb is open, do not even try to send requests, but immediately return an error

Or maybe I do get the idea wrong.

Please help clarify.

[rShetty]

@ybbus This library was built with the above-mentioned decision. Let me research on this topic more. If you have some examples of some other resilience libraries doing it otherwise can you help point me to those?

[0xmichalis]

Based on the MSFT docs on the circuit breaker pattern, it still makes sense to combine retries with CB as long as errors are transient.

The purpose of the Circuit Breaker pattern is different than the Retry pattern. The Retry pattern enables an application to retry an operation in the expectation that it'll succeed. The Circuit Breaker pattern prevents an application from performing an operation that is likely to fail. An application can combine these two patterns by using the Retry pattern to invoke an operation through a circuit breaker. However, the retry logic should be sensitive to any exceptions returned by the circuit breaker and abandon retry attempts if the circuit breaker indicates that a fault is not transient.

https://docs.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker