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

[nreid260]

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)

[globsterg]

The test passes for me, and the JetBrains CI is green (1bffe67). 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.

[fzhinkin]

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?

[nreid260]

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...