I have a spec class that is hanging after the last...

# kotest

[Wesley Hartford]

I have a spec class that is hanging after the last test completes. All tests run and pass, but test execution does not finish. I have a logging listener registered. The afterAny gets called for the last test and the test container, the afterContainer gets called, but the afterSpec function does not get called. Does anyone know what happens between afterContainer and afterSpec that could cause the test execution to hang? Thanks.

[LeoColman]

after project, perhaps?

[Wesley Hartford]

I'm pretty sure afterProject happens after afterSpec, I've added an afterProject log to my test and it does not get called.

[sam]

Do you have anything thready or coroutiny going on in the callbacks ?

[Wesley Hartford]

In beforeSpec, I launch a coroutine in GlobalScope which continues in the background (the tests interact with services running there). That launched job is cancelled in an afterSpec. The test hangs before that afterSpec is called.

[sam]

anything launched in global scope shouldn't matter

[sam]

as different lifestyles

[Wesley Hartford]

That's what I was thinking.

[sam]

if you remove that call does the test complete

[Wesley Hartford]

test cases fail, but the test completes.

[sam]

doesn't hang anymore? So does sound like something in that coroutine is locking it up

[Wesley Hartford]

Yeah, that seems odd though right? It's launched in global scope, so how can it interfere with the completion of the test? I can imagine a case where it might prevent the JVM from shutting down, but how would it prevent the call to afterSpec?

[sam]

yeah it doesn't make much sense to me either

[sam]

Does the launched co routine do anything funky ?

[Wesley Hartford]

That's a good question... this is an integration test, so it starts a handful of other services that the service under test interacts with.

[Wesley Hartford]

In other words, the launched coroutine does a lot of stuff, some of it probably funky.

[sam]

It might be doing something that causes things to hang

[sam]

like a long running thread

[Wesley Hartford]

I've made the test complete by removing the coroutineContext passed to the launch function. I had been passing a modified version of the currentCoroutineContext(), but with no context argument, the test completes.

[Wesley Hartford]

Yeah, it looks like that did it, do you know if something might have changed between 5.6.2 and 5.7.2 to change the behaviour there? The upgrade might have been when the breakage was introduced.

[sam]

not off top of my head but we did do a bunch of work on coroutines in general. I know @Oliver.O knows this stuff pretty well he might be able to help (night time for him right now)

[Wesley Hartford]

🤷 It's working now

[Wesley Hartford]

I might poke around on Monday to see if I can produce a reasonably minimal reproduction.

[sam]

that would be helpful

[Wesley Hartford]

Thanks for your help.

[sam]

np

[Oliver.O]

Stuff hanging before afterSpec is called seems exotic. The common case for a hang on exit is a non-daemon thread.

[Oliver.O]

You could also check for thread starvation. runBlocking should be avoided. Also any kind of dispatcher using a limited thread pool. See here for an explanation why to use Dispatchers.IO.limitedParallelism(…): https://blog.jetbrains.com/kotlin/2021/12/introducing-kotlinx-coroutines-1-6-0/#dispatchers.io-elasticity-for-limited-parallelism

[Wesley Hartford]

So it turns out it's actually really easy to reproduce. Here is a self-contained test class that hangs:

class KotestHangBeforeAfterSpec : FunSpec(
  {
    lateinit var job: Job
    beforeSpec {
      job = GlobalScope.launch(currentCoroutineContext()) { delay(Duration.INFINITE) }
    }

    afterSpec {
      job.cancel()
    }

    test("always pass") {
      assert(true)
    }
  }
)

[Wesley Hartford]

Removing the currentCoroutineContext() argument to the launch function fixes the problem.

[Wesley Hartford]

I've just confirmed that the above test class hangs when using kotest 5.7.2 but does not hang when using kotest 5.6.2.

[sam]

thanks for the reproducer and the deep dive

[sam]

we can look into that

[Wesley Hartford]

Would you like me to make an issue on GitHub?

[sam]

yes please

[Wesley Hartford]

I'll do that in the next few hours. Right now I need to make dinner.

[Wesley Hartford]

https://github.com/kotest/kotest/issues/3759

[Oliver.O]

Cool, thanks! I’ll be looking into it.

[Oliver.O]

OK, got to the root cause after all, so fixing this should not be too hard. But seems like we're already a bit in interesting waters (sort of Gradle-like lazy configuration experience):

because we have various dynamic ways of determining if a test is enabled

https://github.com/kotest/kotest/issues/3534#issuecomment-1656845546