Am I wrong that

CircuitBreaker

only considers exceptions to be cause for breaking? In my case, exceptions are already caught into an

Either

upstream, so I'd rather break on

Either.Left

.

This is currently a bit tricky, but I would actually like to support it easily. There are a couple of options. 1. Expose different combinator for

protectRaise

, or

Either

. Naming will be tricky because we already have

protectEither

which returns

Either

instead of rethrowing the

ExecutionRejected

2. It's possible not possible to distinct between

CancellationException

from Kotlin(X) or Raise, but we could perhaps do that. If we do that, we could automatically increment the counters. By doing this we could perhaps also take that into account in

Schedule#retry

..🤔 What I mean with

2

is:

either {
  schedule.retry { foo().bind() } // retry on Left
  cb.protect { foo().bind() } // increment failure counter 
}

Oh, so there would be a

context(Raise<E>)
inline fun <E> CircuitBreaker.protect(block: context(Raise<E>) () -> Unit)

that has a try-catch on the specific Arrow CancellationException?

It could be completely transparent on top of the current

protect

, currently

NonFatal

are not being counted so

CancellationException

is not being counted

To go in more details of my exact use-case: as part of the Pedestal project I just mentioned, I have a bunch of Cache implementations that layer on top of each other to create complex strategies. Caches are reactive, that is, you can subscribe to a value, and when it gets refreshed, all subscribers are notified (classic

Flow

). In my projects using this architecture, all reads go through caches. Therefore, I think it would be a great place to use Arrow resilience: if for some reason the external service is dead, the cache should use CircuitBreaker (and maybe a retry? not sure) to failfast, serving the last cached value to the user until the service goes back up. Reading the Resilience documentation, this seems appropriate to me, but when trying to implement it, there is one challenge; the operation which may fail is not the one that should be retried. For example, here's how I would implement a naïve RetryCache:

class RetryCache<I, F, V>(val upstream: Cache<I, F, V>) : Cache<I, F, V> by upstream {
    override val get(id: I): Flow<ProgressiveOutcome<F, V>> = upstream[id]
        // subscribe to all results…
        .onEach {
            if (it is ProgressiveOutcome.Failure)
                expire(id) // force a retry if the latest result failed, while still subscribing so we see the next result
        }
}

I'm not really sure how to adapt that to fit the

CircuitBreaker

's expectations.

Uhm, the operation itself occurs in

upstream

, right?

It's layered, and each layer asks the previous to do the operation. I'd like to have the circuit breaker as another layer so it can be composed with everything else

It's layered, and each layer asks the previous to do the operation.

But you cannot wrap the operation, can you? 🤔

Well, the operation is

upstream[]

. But it's a flow.

Right, exactly