Async Control Flow

• pool-conduit

  3 422 8.4 Haskell

  Persistence interface for Haskell allowing multiple storage methods.

  

  I don't think connection is returned to the pool here. The thread is interrupted when query is sent to server, but before the results are consumed. At that point cleanup action catches `ThreadKilled` exceptions and issues `ROLLBACK`, which fails with `libpg` exception because the previous operations was not completed. And now cleanup action rethrows the `libpg` exception instead of the `ThreadKilled` one - that's the behavior of `bracket` from `base`. [The fix](https://github.com/yesodweb/persistent/pull/1207/files#diff-f9d7f232cd00cb88188b7fcc68110e3f4cb378fcad9df652360de44d13cd86e3R199) was to use `bracket` from `unliftio`, which [rethrows the correct exception](https://hackage.haskell.org/package/unliftio-0.2.14/docs/src/UnliftIO.Exception.html#bracket).

• exceptions

  0 46 2.9 Haskell

  mtl friendly exceptions

  I see. Do you think rethrowing the original exception is the the right approach in all cases, or only in this case? In the documentation I wrote for the exceptions package, I recommend to let the release block's exceptions take priority, to match base's behavior. Should I recommend the opposite?

• Scout APM

  scoutapm.com

  sponsored

  Less time debugging, more time building. Scout APM allows you to find and fix performance issues with no hassle. Now with error monitoring and external services monitoring, Scout is a developer's best friend when it comes to application development.

  

• safe-exceptions

  0 126 1.2 Haskell

  Safe, consistent, and easy exception handling

  

  In safe-exception and uniftio it was decided to rethrow the original exception exactly because they decided to use uninterruptibleMask, see here for details.

• postgresql-simple

  0 212 0.0 Haskell

  Mid-level client library for accessing PostgreSQL from Haskell

  Hmm, you are right, the bracket I pointed to is unrelated. I guess the fix is in catchAny, which doesn't catch ThreadKilled. So not it's not rolling the transaction back in case of asynchronous exceptions. My point is that it probably should not rollback even on synchronous exception. BTW the issue is well know, see for example here

Suggest a related project