evolution-gaming / cats-helper Goto Github PK

There is a little inconsistency regarding imports in the library: while any other library (e.g. cats, cats-effect & tofu) import their syntax by import lib.syntax.something._ and import lib.syntax.all._, cats-helper does it in its own unique way by import com.evolutiongaming.SomethingHelper._.

It kind of slows down the adoption by newcomers, because they can easily miss that those syntax objects even exist, so I would like to propose to change this import scheme to be the same as in cats. WDYT?

Another thing I would like to discuss here (I don't think it is worth creating a separate issue for that) is the pollution by apply methods. One can easily find such code in cats-helper (e.g. Blocking, FromFuture):

trait Something[F[_]] {
  def apply(something: Thing): F[OtherThing]
}

object Something {
  def apply[F[_]: Something]: Something[F] = implicitly
}

Not only that it just doesn't work to call it like Something[F](thing) because of double apply and thing being treated as an explicitly passed instance, but IntelliJ IDEA often fails to find usages or asks if I want to go to the instance or to the method. In other words, it is inconvenient. So my proposal is to add alternative methods names with the possible deprecation of apply methods.

I could get this done, but I would like to see some discussion here. Are those proposals any good?

Some cases like skafka #125 required applying ToTry multiple times while accumulating total execution time and firing IO.timeout on its exhaustion.

That can be achieved by implementing factory ToTryOf with API like:

import cats.effect.IO
import cats.effect.unsafe.IORuntime

sealed trait ToTryOf[F[_]] {
  def disposable(timeout: FiniteDuration): F[ToTry[F]]
}

object ToTryOf {
  def ioToTryOf(implicit runtime: IORuntime): ToTryOf[IO] = ???
}

Initially we observed this issue with FeatureToggled. It went like so:

• we have a feature-toggled resource, toggled on and under some use
• we toggle it off
• later we toggle it on, but it does not go back.
  Heap dumps showed that an internal rwLock: ReadWriteRef had a positive number of active tasks despite them being complete long time ago.

We've narrowed down the problem to the incorrect cancellation handling in ReadWriteRef, specifically this bit

val read: Resource[F, A] = {
  Resource.suspend {
    Concurrent.cancelableF[F, Resource[F, A]] { cb =>
      …
      stateRef
        .modify { // acquisition
            …
            val effect = … // emit a Resource that modifies stateRef on release
            val cancel = F.unit
            s1 -> (effect as cancel)
        }
        .flatten
    }
  }

In a nutshell, we have two stateRef updates here: one for "acquisition" and one for "release", but the problem is that they happen on different "layers", and its quite possible that only "acquisition" happens but not "release" when the read.use(…) gets cancelled.