Is it possible to disable the automatic dump of co...

# coroutines

[CLOVIS]

Is it possible to disable the automatic dump of coroutines at the end of tests when debug probes are enabled? I'd like to control the exact time at which it happens.

[Dmitry Khalanskiy [JB]]

Hi! The automatic dump happens if the test fails due to a timeout: https://github.com/Kotlin/kotlinx.coroutines/blob/8c27d51025d56a7b8de8eec2fb234b0094ce84f1/kotlinx-coroutines-test/common/src/TestBuilders.kt#L341 Is this the problematic behavior?
We don't provide a way to configure it. We consider timeouts to be unexpected and unnatural ways for tests to finish, and so wanted to help the programmer diagnose this (hopefully once-in-a-blue-moon) situation.

[CLOVIS]

Is this the problematic behavior?

Yes. I have my own test framework which uses TestScope internally, and I'd like to tweak the way this is printed. For example, to differentiate between foreground and background jobs. I agree it's a very specific use-case, and the current behavior is a good default.

[Dmitry Khalanskiy [JB]]

These are several use cases in one. You say you want to control the time when the debug probes are emitted--what other time is suitable for dumping the coroutines? Also, with our current DebugProbes API, there's no easy way to filter between background and foreground jobs (in the test framework sense, that is, backgroundScope), which I think is a great idea, well worth doing in kotlinx-coroutines-test itself.

If you file an issue, we can consider adding an escape hatch, though I'm hoping that we'll be able to improve the defaults instead.

[CLOVIS]

> what other time is suitable for dumping the coroutines?
In my case, just slightly later, when the error unwinds to my own "failed test detector" instead of the coroutines' one.

> Also, with our current DebugProbes API, there's no easy way to filter between background and foreground jobs
Is that so? DebugProbes.printScope() seems to me that it would be useful here, as the foreground and background jobs are different scopes, but I haven't tried.

At the moment I have an issue that backgroundScope doesn't work in my framework (it behaves in exactly the same way as the foreground scope), even though it's just an accessor for the coroutines' implementation. I'm trying to understand what's going on there, and then I'll file a more detailed issue with the dumping use-case.

[Dmitry Khalanskiy [JB]]

Is that so? DebugProbes.printScope() seems to me that it would be useful here

backgroundScope is a child of TestScope, so printing TestScope will also print the background jobs. Also, this approach will miss the coroutines that aren't (transitively) children of TestScope.

[CLOVIS]

Also, this approach will miss the coroutines that aren't (transitively) children of TestScope.

How can you differentiate between coroutines that aren't children of that TestScope, and coroutines from other tests?

[Dmitry Khalanskiy [JB]]

Good question. You can't, and this is a problem for the test framework as well: https://github.com/Kotlin/kotlinx.coroutines/issues/4265

[CLOVIS]

What I'd probably do:
• At the end of each test, dump only that test's TestScope
• At the end of everything, dump all the coroutines still running

[Dmitry Khalanskiy [JB]]

We don't really have hooks for the end of everything. runTest is our only entry reliable entry point. Maybe this would be possible with a tighter platform test framework integration (for example, if we provided JUnit rules).

[Oliver.O]

There is this new thing called TestBalloon testballoon which does structured concurrency across the entire test session (and a customizable number of hierarchy levels below).