Open brandonchinn178 opened 1 year ago
I'm afraid we can only be hold responsible for the behavior of a vanilla test executable. If stack test
/ cabal test
perform some magic tricks to catch signals, the ball is in their court.
Thanks @Bodigrim opened one here: https://github.com/commercialhaskell/stack/issues/6236
Minimal repro:
Observed behaviors:
threadDelay
pkill -INT
pkill -15
This behavior also happens with
unliftio
'sfinally
, which usesuninterruptibleMask
. It also fails to clean up anybracket
orwithResource
wrapping the entire test, e.g.cleanup
will never be printed in the following snippet:Changing the second
threadDelay
tothreadDelay 1
does clean up, so it's notthreadDelay
itself, just anything taking a long time. In our case, connecting to a postgres database (e.g. withpostgresql-libpq
'sconnectStart
function) in thefinally
block also shows this behavior.This only happens with
stack test
. Manually compiling withghc Main.hs && ./Main
will clean up, andcabal test --test-show-details=streaming
will exit immediately, but finish the cleanup in the background (as a zombie thread?).