OliverO2

@aSemy Maybe you could consider some of the above for #4105 and select the addressed tests in the above list. Let me know if I should fix any of those...

Great, let's do it this way! I'll call it a day for now but if I'll pick stuff, I'll leave a note here. And if I merge with positive CI...

I just had a timeout on a local build with https://github.com/kotest/kotest/blob/0ec32b335362a98390285c6067c2d65f8e2ab581/kotest-runner/kotest-runner-junit5/src/jvmTest/kotlin/com/sksamuel/kotest/runner/junit5/PerformanceTest.kt#L12 This was seemingly caused by a parallel run of `:kotest-framework:kotest-framework-multiplatform-plugin-gradle:check`, which is very resource intensive as it fires up...

OK, seems like there is always the exception to the exception in Gradle 🙃. The tag idea sounds promising. I'll create a separate issue for that.

Well, `async` is suspending, so the border crossing between blocking and suspending worlds happens just at some layer above, where you'll always find some `runBlocking`. The exception is JS, where...

I can try to look at GlobalTimeoutTest tomorrow. `runBlocking` does nothing with threads, just happily runs on the current one. It basically starts an event loop on which it schedules...

Yes, that's also a good idea.

Seems like we cannot proceed with tag-based exclusion due to #4135.

Yep. I guess we're just completing a phase with the largest amount of testing Kotest has seen so far.

Regarding `GlobalTimeoutTest`: I can't see why `TestEngineLauncher.launch()` would not wait until all tests are finished. The `runBlocking`, which it invokes, does. So unless some inner coroutine breaks out of structured...