-
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).
-
CodeRabbit
CodeRabbit: AI Code Reviews for Developers. Revolutionize your code reviews with AI. CodeRabbit offers PR summaries, code walkthroughs, 1-click suggestions, and AST-based analysis. Boost productivity and code quality across all major languages with each PR.
-
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?
-
In safe-exception and uniftio it was decided to rethrow the original exception exactly because they decided to use uninterruptibleMask, see here for details.
-
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