Close client connections when writer is unexpectedly cancelled

[bdraco]

TODO: figure out how to test this

What do these changes do?

If the writer is cancelled out while waiting for the connection to close or release, we now suppress the cancellation to prevent it from leaking upwards and force close the connection to ensure we do not reuse a connection which has an indeterminate state.

#8035 (reply in thread)

Are there changes in behavior for the user?

Related issue number

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]

Codecov Report

Attention: Patch coverage is 66.66667% with 4 lines in your changes missing coverage. Please review.

Project coverage is 97.47%. Comparing base (2670e7b) to head (31f7664).
Report is 1833 commits behind head on master.

Files with missing lines	Patch %	Lines
aiohttp/client_reqrep.py	66.66%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #8041      +/-   ##
==========================================
+ Coverage   97.42%   97.47%   +0.05%     
==========================================
  Files         107      107              
  Lines       32601    32611      +10     
  Branches     3799     3800       +1     
==========================================
+ Hits        31760    31788      +28     
+ Misses        634      620      -14     
+ Partials      207      203       -4     

Flag	Coverage Δ
CI-GHA	97.39% <66.66%> (+0.04%)	⬆️
OS-Linux	97.06% <66.66%> (+0.12%)	⬆️
OS-Windows	95.56% <66.66%> (+0.03%)	⬆️
OS-macOS	96.69% <66.66%> (-0.20%)	⬇️
Py-3.10.11	95.49% <66.66%> (?)
Py-3.10.13	96.86% <66.66%> (-0.02%)	⬇️
Py-3.11.7	96.52% <66.66%> (+0.10%)	⬆️
Py-3.12.1	96.65% <66.66%> (?)
Py-3.8.10	95.46% <66.66%> (-0.02%)	⬇️
Py-3.8.18	96.80% <66.66%> (-0.02%)	⬇️
Py-3.9.13	95.46% <66.66%> (-0.02%)	⬇️
Py-3.9.18	96.83% <66.66%> (-0.02%)	⬇️
Py-pypy7.3.15	96.39% <66.66%> (?)
VM-macos	96.69% <66.66%> (-0.20%)	⬇️
VM-ubuntu	97.06% <66.66%> (+0.12%)	⬆️
VM-windows	95.56% <66.66%> (+0.03%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[Dreamsorcerer]

One concern that occurred to me is what if this is part of a task that is being cancelled by the user? In that case we don't want to suppress.

Ideally, if we can detect if the cancellation is from our client timeout or similar, we'd suppress it, otherwise we'd reraise it. Or something along those lines...

[Dreamsorcerer]

Looks reasonable, but might also need something to handle ClientTimeout. Can't remember exactly how the logic works, but if we hit the timeout at this point, then we probably don't actually want to time out, as we already received the response before the timeout.

[bdraco]

I think thats handled by

aiohttp/aiohttp/client_reqrep.py

Line 570 in 9e14ea1

if exc.errno is None and isinstance(exc, asyncio.TimeoutError):

[bdraco]

Tests are very light for this case so I'll have to work up something from scratch. I'll do that if the issue is confirmed fixed by the op of the discussion

[Dreamsorcerer]

I think this one is actually superseded by #9030.

[bdraco]

closing in favor of #9030