`synchronous queue should not lose takers when offerer is canceled and there are no other takers` flake

[armanbilge]

Observed in 53a9f56.
https://github.com/typelevel/cats-effect/actions/runs/4856733694/jobs/8656584247?pr=3586#step:23:4083

Is it legit or just a flake 😅

cats-effect/tests/shared/src/test/scala/cats/effect/std/QueueSpec.scala

Lines 75 to 99 in 53a9f56

	"not lose takers when offerer is canceled and there are no other takers" in real {
	val test = for {
	q <- Queue.synchronous[IO, Unit]
	latch1 <- IO.deferred[Unit]
	offerer <- IO.uncancelable(p => latch1.complete(()) >> p(q.offer(()))).start
	_ <- latch1.get
	// take and cancel the offerer at the same time
	// the race condition we're going for is *simultaneous*
	// failing to repeat the race is likely, in which case the
	// offerer will be canceled before we finish registering the take
	taker <- IO.both(q.take, offerer.cancel).start
	// if we failed the race condition above, this offer will unblock the take
	// if we succeeded in replicating the race, this offer will have no taker
	// with the bug, this will timeout since both will block
	// with the bug fix, either the join will return immediately, or it will
	// be unblocked by the offer
	_ <- IO.race(taker.joinWithNever, q.offer(()).delayBy(500.millis))
	} yield ()
	test.parReplicateA(if (isJS || isNative) 1 else 1000).as(ok)
	}
	}

[durban]

Wait, why does github create a commit in my name? It even has a fake "verified" green badge, but it was definitely not signed by my key...

(I'm sorry, I have no opinion on the actual issue here :-)

[armanbilge]

This just flaked again in 64e4a30 which includes the placation.
https://github.com/typelevel/cats-effect/actions/runs/4866812053/jobs/8678724394?pr=3332#step:23:4086

[djspiewak]

Concerning. I'll look into it.

[durban]

Yeah, this test can hang, I can reproduce it. I'm not sure if the bug is in the test, or in the queue itself. Although the test seems okay to me.

This looks somewhat suspicious to me, but I'm not entirely sure: https://github.com/typelevel/cats-effect/blob/series/3.x/std/shared/src/main/scala/cats/effect/std/Queue.scala#L194-L196

[durban]

I think there could be a problem with synchronous queue, if take completes the deferred of a cancelling offer here after the finalizer checked it with tryGet here. take will think it succeeded, and suspend (waiting on its own latch). And offer will think it successfully cancelled, and will never complete that latch.

I think this scenario could be consistent with the test hanging, and I don't see anything which would make it impossible...

[djspiewak]

Yeah I think this is absolutely a problem. We're only catching it incidentally in this test (which was designed to caliper down on a different race condition), which is probably why it's so hard to reproduce.

I'm not sure why I made the SyncState so convoluted. It feels like offerers being a ScalaQueue[(A, Deferred[F, Unit])] would be less error-prone.