Skip to content
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

Close a connection if an unexpected exception occurs while sending a request #2828

Merged
merged 3 commits into from
Mar 14, 2018
Merged

Close a connection if an unexpected exception occurs while sending a request #2828

merged 3 commits into from
Mar 14, 2018

Conversation

brycedrennan
Copy link
Contributor

What do these changes do?

Close a connection if an unexpected exception occurs while sending a request

Are there changes in behavior for the user?

No.

Related issue number

Resolves #2827

Checklist

  • I think the code is well written
  • Unit tests for the changes exist
  • Documentation reflects the changes
  • If you provide code modification, please add yourself to CONTRIBUTORS.txt
    • The format is <Name> <Surname>.
    • Please keep alphabetical order, the file is sorted by names.
  • Add a new news fragment into the CHANGES folder
    • name it <issue_id>.<type> for example (588.bugfix)
    • if you don't have an issue_id change it to the pr id after creating the pr
    • ensure type is one of the following:
      • .feature: Signifying a new feature.
      • .bugfix: Signifying a bug fix.
      • .doc: Signifying a documentation improvement.
      • .removal: Signifying a deprecation or removal of public API.
      • .misc: A ticket has been closed, but it is not of interest to users.
    • Make sure to use full sentences with correct case and punctuation, for example: "Fix issue with non-ascii contents in doctest text files."

@codecov-io
Copy link

codecov-io commented Mar 13, 2018

Codecov Report

Merging #2828 into master will not change coverage.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff           @@
##           master    #2828   +/-   ##
=======================================
  Coverage   97.96%   97.96%           
=======================================
  Files          39       39           
  Lines        7426     7426           
  Branches     1305     1305           
=======================================
  Hits         7275     7275           
  Misses         48       48           
  Partials      103      103

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 9108698...e902045. Read the comment docs.

@pfreixes
Copy link
Contributor

@asvetlov and @brycedrennan some comments on this MR and the issue related

  • Using the context manager way of sending a request rather than use an await this issue shouldn't appear, am I right ?

  • And specifically of that MR, Why close and not release? the context manager uses as a teardown the release method.

@asvetlov
Copy link
Member

@pfreixes

  1. Yes, from my understanding context manager should close connection on exception
  2. release returns a connection back to pool. If exception has occurred the connection is in undefined state: it can have not-read-yet data etc. Dropping the connection entirely by close() is safer.

@brycedrennan
Copy link
Contributor Author

brycedrennan commented Mar 13, 2018

@pfreixes

  1. It doesn't appear to help to use the context manager. I modified the test to use the context manager and it still has trouble without the fix.

  2. I don't know the difference. I used close because thats what was used to handle exceptions during .start

Copy link
Member

@kxepal kxepal left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGFM, but there is one little bit...

@@ -379,6 +380,42 @@ def test_context_manager(connector, loop):
assert e.strerror == err.strerror


async def test_close_conn_on_error(create_session):
class UnexpectedException(Exception):
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your try/except block catches BaseExceptions, but here you test just for Exception. It's easy to change the code and break the behavior, but not the tests.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

resp = await req.send(conn)
except BaseException:
conn.close()
raise
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems we're don't the same thing twice. How about to regroup try/except a bit?

try:
  resp = await req.send(conn)
  try:
    await resp.start(conn, read_unit_eof)
  except:
    resp.close()
    raise
except:
  conn.close()
  raise

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

@kxepal
Copy link
Member

kxepal commented Mar 13, 2018

And sign question about context managers. It's strange that they doesn't helps.

@kxepal
Copy link
Member

kxepal commented Mar 13, 2018

@brycedrennan Thanks!

Change test to use context manager, BaseException
@pfreixes
Copy link
Contributor

pfreixes commented Mar 13, 2018

Checked, sorry for the noise but finally I was able to connect all of the dots, I would like to propose a silly change in this MR.

The context manager is not able to close the connection because there is no response yet and won't be able to make it. My bet is that with your example @brycedrennan related with the context manager you are having another exception raised within the original exception.

Basically, the change that I propose is adding a check to make sure that the resp attribute is present [1].

Thoughts @asvetlov and @brycedrennan ?

[1] https://github.com/aio-libs/aiohttp/blob/master/aiohttp/client.py#L790

@brycedrennan
Copy link
Contributor Author

brycedrennan commented Mar 13, 2018

@pfreixes __aexit__ is never called because the exception is thrown during __aenter__. I just put some breakpoints in the debugger, and confirmed by adding a try/except into the __aenter__.

Also the test is catching the specific exception that was thrown.

@pfreixes
Copy link
Contributor

@brycedrennan my fault I was totally confused, the exception happens in the __aenter__ so as you said the __aexit__ is not called.

Forget my comment. The response and the connection teardown in case of exception within Client.__request can't rely on the context manager.

@asvetlov
Copy link
Member

Everything looks good, will merge tomorrow if nobody objects.
The PR should be backported to 3.0 branch and new 3.0.x release should be published (I'll do it myself).
@brycedrennan thanks for your work!

@asvetlov asvetlov merged commit 4534021 into aio-libs:master Mar 14, 2018
@brycedrennan brycedrennan deleted the header-error-cleanup branch March 15, 2018 05:22
@lock
Copy link

lock bot commented Oct 28, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a [new issue] for related bugs.
If you feel like there's important points made in this discussion, please include those exceprts into that [new issue].
[new issue]: https://github.com/aio-libs/aiohttp/issues/new

@lock lock bot added the outdated label Oct 28, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Oct 28, 2019
@psf-chronographer psf-chronographer bot added the bot:chronographer:provided There is a change note present in this PR label Oct 28, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bot:chronographer:provided There is a change note present in this PR outdated
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Exception handling doesn't close connection
5 participants