kotlinx.coroutines icon indicating copy to clipboard operation
kotlinx.coroutines copied to clipboard

1.9.0-RC: DispatchersToStringTest.testLimitedParallelism fails when CORE_POOL_SIZE == 2

Open nreid260 opened this issue 1 year ago • 3 comments
trafficstars

I'm seeing this when testing with Bazel. The failing case seems somewhat unnecessary since the function being tested is @Deprecated.

org.junit.ComparisonFailure: expected:<Dispatchers.Default[.limitedParallelism(2)]> but was:<Dispatchers.Default[]>
	at org.junit.Assert.assertEquals(Assert.java:117)
	at kotlin.test.junit.JUnitAsserter.assertEquals(JUnitSupport.kt:32)
	at kotlin.test.AssertionsKt__AssertionsKt.assertEquals(Assertions.kt:63)
	at kotlin.test.AssertionsKt.assertEquals(Unknown Source)
	at kotlin.test.AssertionsKt__AssertionsKt.assertEquals$default(Assertions.kt:62)
	at kotlin.test.AssertionsKt.assertEquals$default(Unknown Source)
	at kotlinx.coroutines.DispatchersToStringTest.testLimitedParallelism(DispatchersToStringTest.kt:20)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:59)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:61)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:308)
	at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:368)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:103)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:63)
	at org.junit.runners.ParentRunner$4.run(ParentRunner.java:333)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:81)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:331)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:295)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:308)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:420)
	at org.junit.runners.Suite.runChild(Suite.java:128)
	at org.junit.runners.Suite.runChild(Suite.java:27)
	at org.junit.runners.ParentRunner$4.run(ParentRunner.java:333)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:81)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:331)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:295)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:308)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:420)
	at com.google.testing.junit.runner.internal.junit4.CancellableRequestFactory$CancellableRunner.run(CancellableRequestFactory.java:108)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:141)
	at org.junit.runner.JUnitCore.run(JUnitCore.java:119)
	at com.google.testing.junit.runner.junit4.JUnit4Runner.run(JUnit4Runner.java:100)
	at com.google.testing.junit.runner.RunnerShell$2.run(RunnerShell.java:34)
	at com.google.testing.junit.runner.GoogleTestRunner.runTestsInSuite(GoogleTestRunner.java:179)
	at com.google.testing.junit.runner.GoogleTestRunner.runTestsInSuite(GoogleTestRunner.java:162)
	at com.google.testing.junit.runner.GoogleTestRunner.main(GoogleTestRunner.java:122)

nreid260 avatar Jun 06 '24 00:06 nreid260

The test passes for me, and the JetBrains CI is green (https://github.com/Kotlin/kotlinx.coroutines/commit/1bffe67a32d9d0285320f5b23fa94bc2b5f2b92e). So, seems like an issue on your side.

Also, the single-parameter limitedParallelism overload isn't simply deprecated, it's replaced with a two-parameter overload where the second parameter has a default value, so passing just one parameter should still work.

globsterg avatar Jun 06 '24 04:06 globsterg

The failing case seems somewhat unnecessary since the function being tested is @deprecated.

limitedParallelism(parallelism: Int, name: String? = null) is not deprecated, and limitedParallelism(2) at the problematic call site resolves to it, not to a deprecated overload.

Anyway, @nreid260 could you please elaborate on how to reproduce the issue?

fzhinkin avatar Jun 06 '24 14:06 fzhinkin

The test outcome depends on the available parallelism of the test environment. So it's deterministic, but it will always fail for some users.

The bug appears to be in kotlinx-coroutines-core/jvm/src/scheduling/Dispatcher.kt. There's a branch on available parallelism:

if (parallelism >= CORE_POOL_SIZE) {
  return namedOrThis(name)
}

This makes me wonder what other behaviors aren't being tested because of the test env configuration...

nreid260 avatar Jun 06 '24 16:06 nreid260