-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't run ROLLBACK when the connection is closed. #778
Don't run ROLLBACK when the connection is closed. #778
Conversation
This can be caused when a query times out while running, for example, and the connection is closed as a result (as opposed to cancelling the query, since PR aio-libs#570). In this case, we would rather not emit the ROLLBACK (the connection is already closed, so the transaction is over anyway), rather than raising an exception when trying to use a connection which is already closed. See issue aio-libs#777.
d576656
to
5408cac
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you please add the same test for asyncio.CancelledError?
Codecov Report
@@ Coverage Diff @@
## master #778 +/- ##
==========================================
+ Coverage 93.10% 93.20% +0.10%
==========================================
Files 13 13
Lines 1537 1545 +8
Branches 172 176 +4
==========================================
+ Hits 1431 1440 +9
+ Misses 78 76 -2
- Partials 28 29 +1
Continue to review full report at Codecov.
|
@Pliner have you had a chance to go over this again? |
Sure, I have. I'm a bit unsure about the way how it's resolved in PR, let me try to propose alternative one in a couple of days. |
@Pliner bump? |
@brianmaissy thanks for your contribution and sorry for the long delay. I've slightly modified PR and it is merged to master now. I'm going to create new dev version today. |
Fixes #777.
This can be caused when a query times out while running, for example, and the connection is closed as a result (as opposed to cancelling the query, since PR #570). In this case, we would rather not emit the ROLLBACK (the connection is already closed, so the transaction is over anyway), rather than raising an exception when trying to use a connection which is already closed.
I wasn't sure if it was cleaner to do this here (inside the implementation of rollback) or in the context manager of the transaction. The disadvantage of this implementation is that here we are also affecting any rollback that someone does manually, but implementing it in the context manager is awkward since it doesn't have access to the connection object, and we wouldn't have a way to set
self._transaction = None
andself._is_begin = False
.If you think the side effect of making all ROLLBACKs on a closed connection silently do nothing is fine, we can leave it like this. Otherwise maybe we can add another intermediate method
rollback_unless_closed
or something like that which the context manager calls, which does the check and calls rollback if necessary.