-
Notifications
You must be signed in to change notification settings - Fork 296
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
AsyncFailsafe#future(...)
should completeExceptionally(...)
not raise
#84
Comments
AsyncFailsafe#future(...)
should completeExceptionally() not raiseAsyncFailsafe#future(...)
should completeExceptionally(...)
not raise
Hi Brian, You are right - the current behavior is to immediately throw Just to make sure I understand your scenario and have it covered, do you mind sharing an example/test case? |
…ny fallback handling) when CircuitBreakerOpenException occurs immediately upon invocation. Fixes #84.
This has been released in 1.0.4. |
Fabulous, thank you! |
…ny fallback handling) when CircuitBreakerOpenException occurs immediately upon invocation. Fixes failsafe-lib#84.
If the circuit is open, I expect the
CompletableFuture
returned byAsyncFailsafe#future(...)
to be already completed with the circuit open, rather than have thefuture
method raise an exception.A common case of CF oriented APIs is combing them for fan-out type behavior, particularly in the case where they are being used with a circuit breaker. In that case, the failure handling is usually baked into the CF graph, NOT in the construction of the CF graph.
The text was updated successfully, but these errors were encountered: