Arrow 2.0 Resilience

[serras]

According to our plan (laid our in #2778), we want to split a few classes to a new library, targeting resilience.

• Split CircuitBreaker and Schedule into its own package
• Provide Kotlin-native implementation of Resilience4j's core modules
  • Bulkhead
  • RateLimiter
  • TimeLimiter

[github-actions]

Kover Report

File	Coverage [62.04%]
arrow-libs/fx/arrow-fx-coroutines/src/commonMain/kotlin/arrow/fx/coroutines/flow.kt	78.46%
arrow-libs/fx/arrow-fx-resilience/src/commonMain/kotlin/arrow/fx/resilience/CircuitBreaker.kt	69.30%
arrow-libs/fx/arrow-fx-resilience/src/commonMain/kotlin/arrow/fx/resilience/Schedule.kt	52.35%
arrow-libs/fx/arrow-fx-resilience/src/commonMain/kotlin/arrow/fx/resilience/flow.kt	100.00%

Total Project Coverage	40.32%

[nomisRev]

I think we can/should do this in 1.x.x directly, it doesn't impact any of the existing binaries and that allows us to easily deprecate / migrate in 1.x.x. WDYT?

I discussed some of these types with @raulraja in the past, but at the time we felt that these need some kind-of distributed state 🤔

 - [ ] Bulkhead
 - [ ] RateLimiter
 - [ ] TimeLimiter

Some features I am missing currently:

• CircuitBreaker is sliding-window reset, and perhaps some other reset mechanism.
• Remove dependent type type machinery from Schedule + improve test coverage / fix outstanding bugs.

[serras]

I'm fine with any choice you make, I just made the list because in one of the Arrow meetings we discussed being on par with other resilience libraries, but in pure Kotlin.

I'm not entirely sure about back-porting this to 1.x, since we cannot deprecate a package in such a simple way as we do with types. But if you prefer to do so to make transition easier, I'm happy to back-port it.

[nomisRev]

I'm fine with any choice you make, I just made the list because in one of the Arrow meetings we discussed being on par with other resilience libraries, but in pure Kotlin.

yes, that’s awesome. Thank you so much 🙏 Just wanted to open the discussion ☺️

I'm not entirely sure about back-porting this to 1.x, since we cannot deprecate a package in such a simple way as we do with types. But if you prefer to do so to make transition easier, I'm happy to back-port it.

Right, I was thinking to deprecate the types with a message saying “Add Resilience dependency, and change package”. Could even add a ReplaceWith.

Since it’s non-breaking, it might be better to give a grace period with deprecation. WDYT?

[serras]

Superseded by #2885