Finalizers not executed when fiber canceled quickly after start

[TomasMikula]

If a fiber is successfully started (via start or supervise), I'd naturally expect it's finalizers (guarantee, guaranteeCase) to be guaranteed to execute. That's not what happens.

By successfully started, I mean that the respective effect, start or supervise, completed successfully.

Reproduction

Cats Effect version: 3.6.3

Below are reproductions using both

• start (see object StartAndCancel), and
• Supervisor#supervise (see object SupervisorRelease)

to start fibers.

import cats.effect.std.Supervisor
import cats.effect.{ExitCode, IO, IOApp, Ref}

object StartAndCancel extends FiberFinalizationTest {

  override def startAndCancelTask(task: IO[Unit]): IO[Unit] =
    task
      .start
      .flatMap(_.cancel) // since `start` completed, `task` finalizers should run, but sometimes don't

}

object SupervisorRelease extends FiberFinalizationTest {

  override  def startAndCancelTask(task: IO[Unit]): IO[Unit] =
    Supervisor[IO]
      .use { supervisor =>
        supervisor.supervise(task)
      } // since `supervise` completed, `task` finalizers should run, but sometimes don't
      .void

}

abstract class FiberFinalizationTest extends IOApp {

  def startAndCancelTask(task: IO[Unit]): IO[Unit]

  override def run(args: List[String]): IO[ExitCode] =
    runTestN(100)
      .as(ExitCode.Success)

  private def runTestN(n: Int): IO[Unit] =
    runTest
      .parReplicateA(n)
      .flatMap { results =>
        val succeededCount = results.count(_ == true)
        val failedCount = results.count(_ == false)
        IO.println(s"Succeeded $succeededCount, failed $failedCount.")
      }

  private def runTest: IO[Boolean] =
    for {
      ref <- Ref[IO].of(0)
      _ <- startAndCancelTask(mkTask(ref))
      result <- ref.get
    } yield result == 3

  private def mkTask(ref: Ref[IO, Int]): IO[Unit] =
    IO
      .unit
      .guarantee(ref.update(_ + 1))
      .guaranteeCase(_ => ref.update(_ + 2))

}

Output

When running the above two programs, I get

StartAndCancel

Succeeded 0, failed 100.

I.e. all 100 runs failed to execute finalizers.

SupervisorRelease

Succeeded 61, failed 39.

I.e. 39 out of 100 runs failed to execute finalizers.

[TomasMikula]

I suspect the above behavior of start causes Supervisor itself to leak resources, as Supervisor implementation uses start with guarantee and guaranteeCase to run some cleanups, but those cleanups are not guaranteed to run.

[durban]

I don't know about Supervisor, but for the simple .start: isn't the fiber cancelled before task? Or do you see this behavior even when task actually starts executing?

[TomasMikula]

isn't the fiber cancelled before task?

That's my guess, too. But I would expect reasonable guarantees from .start: if it accepted a task for execution, I'd expect finalizers to run no matter what.

[durban]

On the one hand, yes, that would be somewhat intuitive. On the other hand: if task did not start executing, why would its finalizer run? Similarly:

task1.guarantee(fin1) *> task2.guarantee(fin2)

If this is cancelled at the *> (i.e., before task2), then fin2 won't run.

[TomasMikula]

There would have to be special treatment of the outermost finalizer. That would break the monad laws, as e.g. task.guarantee(fin).flatMap(pure) would not equal task.guarantee(fin), but .flatMap(pure) already changes behavior wrt. cancelation. So it would not be the first weird thing.

Is it possible to implement the desired behavior myself, as

def start[A](task: IO[A], finalizer: IO[Unit]): IO[FiberIO[A]]

which would guarantee finalizer execution after task terminates?

[durban]

1. Depending on the specific use case, it might be appropriate to wait until the fiber actually starts executing. Something like this:

  def startAndWaitForItToReallyStart[A](fa: F[A], fin: F[Unit]): F[Fiber[F, Throwable, A]] = {
    F.deferred[Unit].flatMap { latch =>
      val tsk = F.uncancelable { poll =>
        latch.complete(()) *> poll(fa)
      }.guarantee(fin)
      F.uncancelable { _ =>
        F.start(tsk) <* latch.get
      }
    }
  }

The "trick" here is that we don't "publish" the fiber until it's really running, so there is no way for it to be externally cancelled (and self-cancellation can only happen in fa at the earliest).

2. Another approach is to have a side channel Ref[F, Boolean] to see whether the finalizer ran (after the fiber is joined). (Supervisor does something like that internally, if I remember correctly.)

3. (Depending on the specific use case, other solutions might be possible, which are less general than these.)

---

By the way, start is intentionally low-level. I think usually .background and Supervisor are recommended as higher-level alternatives. (Although I can see that Supervisor doesn't do what you want here.)

[TomasMikula]

Thanks, I have used the "latch" approach to await fiber start, although I didn't use any uncancelable - I don't quite see the reason for them.

My actual use case is indeed Supervisor.

Unfortunately, this workaround of deferring publication of the fiber does not translate to Supervisor, as the Supervisor itself could be finalized and cancel the fiber before it started.

2. Another approach is to have a side channel Ref[F, Boolean] to see whether the finalizer ran (after the fiber is joined).

I would have to spawn a fiber to just join that fiber, as I don't otherwise join it.

A start-with-finalizer primitive would really make things simpler, sigh.

[durban]

The uncancelable around F.start(tsk) <* latch.get is so that we don't "lose" the new fiber if the fiber executing startAndWaitForItToReallyStart is cancelled. The other one is indeed probably unnecessary.

I still don't quite understand your use case, but have you looked at Supervisor with await = true? That one joins fibers instead of cancelling them.

[TomasMikula]

The uncancelable around F.start(tsk) <* latch.get is so that we don't "lose" the new fiber if the fiber executing startAndWaitForItToReallyStart is cancelled.

Not sure that it makes any difference to defer cancelation after latch.get, as opposed to between F.start(tsk) and latch.get.

I still don't quite understand your use case, but have you looked at Supervisor with await = true? That one joins fibers instead of cancelling them.

But I do want Supervisor to cancel fibers on release (and execute their finalizers).

I am going to manage using the "latch" workaround after all, but only because I call supervisor.supervise(...) <* latch.get from within the Supervisor lifecycle, so the supervisor is not going to be released without the fiber waiting on latch.get also being canceled.

[durban]

Not sure that it makes any difference to defer cancelation after latch.get, as opposed to between F.start(tsk) and latch.get.

It can make a difference, if the whole thing is inside an uncancelable/poll:

F.uncancelable { poll =>
  poll(startAndWaitForItToReallyStart(x, fin)).flatMap { fib =>
    ... // do something with `fib`
  }
}

In this case, if we disallow cancellation between F.start(tsk) and latch.get, we can be sure, that if the fiber is forked, then we will "do something" with it. However, if we allow cancellation there, we might "lose" a new fiber.

(Of course, this might not matter in your case.)

[djspiewak]

I see this has been discussed pretty thoroughly already, but what you're pointing at here is the fact that start does not latch. It's basically fire and forget within the scheduler, and that is by design. Another way of saying this is that there are no particular guarantees about when the fiber starts, only that it will be started, so you can absolutely engineer race conditions (like canceling it before it starts).

There are a couple valid semantics here, but we decided that the sanest thing to do if you cancel a fiber before it starts is to just never run it and set its outcome to Canceled. This in turn naturally means that finalizers, even the outermost finalizer, will never be registered and thus naturally will never run. We did think a bit about providing special guarantees around the outermost layer, but it gets super hairy because even guarantee isn't primitive! The actual primitives here are onCancel and uncancelable, with the expectation that you'll leverage flatMap and closure capture to pass resources along to the former within the latter. But this is super tricky then because we would basically need to special case all of that, and then where does it end?

It's easier to just force users to be explicit about this by creating a Deferred which they complete within the fiber, then get that deferred outside of the fiber. We use this pattern a lot within tests, and it's a pretty common solution when this problem arises in more practical contexts. It does (obviously) have some performance impacts, but those impacts are exactly the same as the impact you would see on every start if we tried to provide this guarantee universally (even when it isn't needed), which is part of why we don't try. The other part of why we don't try is the fact that, by completing the Deferred explicitly, you're encoding the answer to "where does it end?", whereas we would need to infer this otherwise.

[TomasMikula]

Then forget about special handling of the outer-most guarantee / onCancel. It would just make a lot of code much simpler and more reliable if there was a primitive

def start(task: IO[A], finalizer: IO[Unit]): IO[FiberIO[A]]

which guarantees execution of finalizer whenever start completes successfully.

Anyway, I'm curious about how #4490 can be fixed.

[TomasMikula]

So the fix of #4490 proposed by @durban in #4500 is to start another, anonymous fiber to execute the finalizer after joining the original fiber.

I think that could be used as the default implementation of the method proposed in my previous comment, added GenSpawn. Thoughts?