`WorkerThreadNameSpec` seems a bit flaky in CI

[djspiewak]

[info] WorkerThread should
[error]   x rename itself when entering and exiting blocking region
[error]    blocker thread not found after reset (WorkerThreadNameSpec.scala:84)

[armanbilge]

Do you have any more context for this? I've been seeing this exclusively on Windows I think, I wonder if we should just disable it specifically in that case.

[djspiewak]

This was indeed a windows run. Any idea what would be specific to windows about this test? I know their thread scheduler is a bit different but it would really surprise me if it would have this kind of impact.

[armanbilge]

Flaked again in a397d484a062b288825ea4715bfbda6b53e2d7db: https://github.com/typelevel/cats-effect/actions/runs/5383736819/jobs/9770840776?pr=3708

[aeons]

This was reported in #3216 back in March and "fixed"/ignored in #3484, but it looks like that was rolled back.

Seems there was a merge of other changes to that file that was from before #3484: https://github.com/typelevel/cats-effect/commits/series/3.x/tests/jvm/src/test/scala/cats/effect/unsafe/WorkerThreadNameSpec.scala

[aeons]

The majority of my contributions to cats-effect have been fixing a test I introduced :D

[armanbilge]

but it looks like that was rolled back.

Oh, I'm so sorry about that! Thanks for following up, yet again 😅

[aeons]

The linked PR was merged, but changed the blocking thread termination time instead. Should we close this and reopen if it didn't fix it?

[armanbilge]

Yup, sorry, GH doesn't auto-close issues when the PR is merged to a non-default branch. Thanks!

[samspills]

This flaked again for me: 685b9a69ec9fb08414a8f4db96473a56ee8d923c https://github.com/typelevel/cats-effect/actions/runs/5549241691/jobs/10133111966?pr=3749#step:24:3264

[error]   x rename itself when entering and exiting blocking region
[error]    blocker thread not found after reset (WorkerThreadNameSpec.scala:87)

[armanbilge]

Again in 3c8459b229fac279d34304cf00bebce763b618c1.

https://github.com/typelevel/cats-effect/actions/runs/5779110056/job/15661495447?pr=3760#step:20:3266

[armanbilge]

Also I just noticed that the flake Sam reported in https://github.com/typelevel/cats-effect/issues/3704#issuecomment-1635119730 was on Ubuntu, not Windows as usual.

[arosien]

I can reliably get a weird result using this program, thought it might be useful for the issue even if it isn't using the actual test:

//> using scala 2
//> using dep org.typelevel::cats-effect::3.5.3

import cats.effect._

object InitialThreadType extends IOApp.Simple {
  def run: IO[Unit] =
    current.debug() *>
      current.debug() *>
      IO.unit

  val current = IO(Thread.currentThread.getName)
}

On my system (mac, jvm 17) it (reliably) prints the second effect with the blocker thread name (but shouldn't):

 *  Executing task: /"Users"/"arosien"/".sdkman"/"candidates"/"java"/"17.0.8-tem"/"bin"/"java"  -classpath "/Users/arosien/arosien/scratch/ce3-initial-thread/.metals/.tmp/classpath_055A2FFD556C81BA440545E91792C958.jar" InitialThreadType  

DEBUG: Succeeded: io-compute-3
DEBUG: Succeeded: io-compute-blocker-3

(update) introducing a cede avoids the issue:

current.debug() *>
+ IO.cede *>
  current.debug() *>
  IO.unit

[arosien]

oops, what i posted is expected behavior (https://typelevel.org/cats-effect/docs/faq#why-is-my-io-running-on-a-blocking-thread) thanks to @armanbilge for pointing that out.