`fs2.interop.flow.PublisherToSubscriberSpec.should cancel upstream if downstream completes` flake

[armanbilge]

3b56691a0830580ea113ef391c2fc169a6f17b97

ubuntu-latest, 3, temurin@17, rootJVM

Unfortunately, ScalaCheck minimized the buffer size argument to zero, which is invalid, so I think we lost the original error ...

==> X fs2.interop.flow.PublisherToSubscriberSpec.should cancel upstream if downstream completes  0.565s munit.FailException: Failing seed: 82KDw0NDjWAXJUVVYTrYStmnTfKrZEE9oA8wbVXJAuG=
You can reproduce this failure by adding the following override to your suite:

  override def scalaCheckInitialSeed = "82KDw0NDjWAXJUVVYTrYStmnTfKrZEE9oA8wbVXJAuG="

Exception raised on property evaluation.
> ARG_0: List(2147483647)
> ARG_1: List(923319774, 2147483647, -140306582, 2147483647, -2147483648, 1239258450, -154613030)
> ARG_2: 0
> ARG_2_ORIGINAL: 41
> Exception: java.lang.IllegalArgumentException: requirement failed: The buffer size MUST be positive
    at munit.Assertions.fail(Assertions.scala:256)
    at munit.Assertions.fail$(Assertions.scala:16)
    at munit.FunSuite.fail(FunSuite.scala:11)
    at munit.ScalaCheckEffectSuite.munit$ScalaCheckEffectSuite$$parseTestResult(ScalaCheckEffectSuite.scala:80)
    at munit.ScalaCheckEffectSuite.checkPropF$$anonfun$2(ScalaCheckEffectSuite.scala:68)
    at apply @ munit.CatsEffectAssertions.assertIO$$anonfun$1(CatsEffectAssertions.scala:52)
    at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
    at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
    at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
    at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
    at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
    at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
    at modify @ fs2.internal.Scope.open$$anonfun$1(Scope.scala:149)
    at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
    at uncancelable @ fs2.Compiler$Target.uncancelable(Compiler.scala:165)
    at rethrow$extension @ fs2.Compiler$Target.compile$$anonfun$1(Compiler.scala:157)
    at get @ fs2.internal.Scope.openScope(Scope.scala:278)
    at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
    at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
    at flatMap @ fs2.Pull$.fs2$Pull$$$_$interruptGuard$1(Pull.scala:951)

https://github.com/typelevel/fs2/actions/runs/13606087216/job/38037727735#step:11:3612

cc @BalmungSan

[arnavsharma990]

@armanbilge could you assign me to solve this issue

[BalmungSan]

Hi @arnavsharma990 we believe we already fixed the issue here: https://github.com/typelevel/fs2/pull/3545 However, we haven't been able to reproduce the problem locally. Thus, we are not sure if we did fixed it or if we were just lucky with the pipeline.

If you want to take a look at this, the first thing would be to see if you can reproduce the bug in the current main branch. But, TBH, I am out of ideas, we already tried running the tests with 1, 2 and 4 active CPUs for the JVM, as well as a playing with the heap size. To try to reproduce the ambient of the Github Actions runners.

 lazy val coreJVM = core.jvm
   .settings(
     Test / fork := true,
+    Test / javaOptions += "-XX:ActiveProcessorCount=4",
+    Test / javaOptions += "-Xms8g",
+    Test / javaOptions += "-Xmx12g",
     libraryDependencies ++= Seq(

And then only running the full flow suite:

sbt:root> coreJVM/testOnly fs2.interop.flow.*