You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
test: Sleeping...finally.1finally.2foo> Test suite foo-test failedTest suite failure for package foo-0.1 foo-test: exited with: ExitFailure (-2)Logs printed to console
pkill -15
test: Sleeping...finally.1finally.2foo-test: SignalException 15foo> Test suite foo-test failedTest suite failure for package foo-0.1 foo-test: exited with: ExitFailure 1Logs printed to console
This behavior also happens with unliftio's finally, which uses uninterruptibleMask. It also fails to clean up any bracket or withResource wrapping the entire test, e.g. cleanup will never be printed in the following snippet:
main = defaultMain $
withResource (putStrLn"setup") (\_ ->putStrLn"cleanup") $\_ ->-- same code as above
Changing the second threadDelay to threadDelay 1does clean up, so it's not threadDelay itself, just anything taking a long time. In our case, connecting to a postgres database (e.g. with postgresql-libpq's connectStart function) in the finally block also shows this behavior.
This only happens with stack test. Manually compiling with ghc Main.hs && ./Main will clean up, and cabal test --test-show-details=streaming will exit immediately, but finish the cleanup in the background (as a zombie thread?).
The text was updated successfully, but these errors were encountered:
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.
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?).The text was updated successfully, but these errors were encountered: