kotlinx-coroutines-test TestMainDispatcher concurrent read/write is difficult to debug

[mcumings]

Current Behavior (1.6.3)

The TestMainDispatcher is wrapped as a delegate within NonConcurrentlyModifiable which tests for concurrent writes while the dispatcher is being read or written. If concurrent writes are detected (which can happen via both the reader and the writer) then an exception is raised and thrown upon the next write.

The above logic results in the failure mode throwing an exception with a stack trace similar to the following (for the write detected while reading scenario):

Dispatchers.Main is used concurrently with setting it
java.lang.IllegalStateException: Dispatchers.Main is used concurrently with setting it
	at kotlinx.coroutines.test.internal.TestMainDispatcher$NonConcurrentlyModifiable.concurrentRW(TestMainDispatcher.kt:70)
	at kotlinx.coroutines.test.internal.TestMainDispatcher$NonConcurrentlyModifiable.setValue(TestMainDispatcher.kt:84)
	at kotlinx.coroutines.test.internal.TestMainDispatcher.resetDispatcher(TestMainDispatcher.kt:40)
	at kotlinx.coroutines.test.TestDispatchers.resetMain(TestDispatchers.kt:37)
	at com.elided.TestCoroutineRule.after(TestCoroutineRule.kt:40)
	at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:59)
	at org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:61)
	at org.mockito.internal.junit.JUnitSessionStore$1.evaluateSafely(JUnitSessionStore.java:55)
	at org.mockito.internal.junit.JUnitSessionStore$1.evaluate(JUnitSessionStore.java:43)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.BlockJUnit4ClassRunner$1.evaluate(BlockJUnit4ClassRunner.java:100)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:366)
	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:331)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:79)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:329)
	at org.junit.runners.ParentRunner.access$100(ParentRunner.java:66)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:293)
	at org.junit.runners.ParentRunner$3.evaluate(ParentRunner.java:306)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:413)
	[ …elided for brevity… ]

Interpreting the above, the test had completed and the test dispatcher was being reset via test rule. While that was taking place, unidentified leaked async code was attempting to get the dispatcher. Not enough information is presented to identify the location of the problematic code - only that there is such code.

Desired Behavior

It would be very helpful if the exception thrown included stack frame information for both actors in the problem space. i.e., both the reader+writer or the writer+writer. Doing so would expose the problematic code and simplify diagnosis.