Adding changes in #335 by @kayslay to handle transaction panic

[paganotoni]

Original comment was:

Handle panic that comes from the fn func(tx *Connection) parameter.

Whenever a panic occurs in a Connection.Transaction the TX.Rollback or TX.Commit is not called after the panic has been recovered. Any call to the Connection.Transaction would block forever.

Thanks @kayslay

cc @stanislas-m @kayslay

[aeneasr]

Shouldn't we rather look into what's causing the panic?

[paganotoni]

Ah! Fair point. Honestly I'm not sure how the underlying layers of transaction work in Pop and just wanted to bring this PR up in case it still relevant. Will take a look.

[aeneasr]

It's also possible that the user is running into panics in her/his code and the panic just bubbles up. In that case however I don't think that pop should be the one recovering it but rather the user's middleware for example. Did the original issue include a stack trace for the panic?

[paganotoni]

It did not, lets just close this one and maybe take a look when we have a concrete case. So far I don't have a way to reproduce it. Thanks @aeneasr

[sio4]

I found this closed PR during branch cleanup. The same issue was addressed with two PRs below, and there are also related fixes on Buffalo core side too. (leaving this comment just for a note with references)

• catch panic within transaction to complete rollback (fixes #748) #775
• do not swallow panic when rolling back inner panic to prevent connection leak #797