custom order of fault tolerance strategies in programmatic API

[Ladicek]

The MicroProfile Fault Tolerance specification prescribes order in which fault tolerance strategies must apply. That's fine (and there's no other way) for the declarative API, but the programmatic API should offer a way to customize the order. In such case, certain fault tolerance strategies can even apply multiple times (fallback most importantly, because in the middle of the fault tolerance strategies chain, there's no other way how to handle exceptions). I'm thinking something like FaultTolerance.create().customOrder()...:

• customOrder() must be called before any fault tolerance strategy is added
• if called, order of adding strategies to the builder becomes meaningful -- it is the order in which the strategies will be applied

[magicprinc]

Your current order is quite standard in industry.
The Resilience4j Aspects order is the following:
Retry ( CircuitBreaker ( RateLimiter ( TimeLimiter ( Bulkhead ( Function ) ) ) ) )

Could I propose a simpler enhancement first:
allow user to add additional Fault Tolerance Strategy at the beginning and
at the end of chain (direct around Callable/before Bulkhead and after Fallback / before returning result to user)

[Ladicek]

I certainly don't intend to make FaultToleranceStrategy a public API. But specifically for adding something at the beginning or at the end, that should already be pretty simple, you just wrap the Callables yourself.

[magicprinc]

for adding something at the beginning or at the end, that should already be pretty simple, you just wrap the Callables yourself.

This is an obvious solution, no surprise :-)
But Callable doesn't have InvocationContext.
In the absence of which, you have to build your own session context infrastructure.

Here is a draft of a simple idea, how to improve the situation
#924

BTW One of thing I miss from failsafe is
https://failsafe.dev/execution-context/