[issue36709] Asyncio SSL keep-alive connections raise errors after loop close.

Andrew Svetlov added the comment: Thanks! -- resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker ___ __

[issue36709] Asyncio SSL keep-alive connections raise errors after loop close.

Kumar Aditya added the comment: The original issue is fixed on main branch with bpo-44011 GH-31275, It now only raises warnings but no exceptions: --- (env) @kumaraditya303 ➜ /workspaces/cpython (latin1 ✗) $ python main.py /workspaces/cpyt

[issue36709] Asyncio SSL keep-alive connections raise errors after loop close.

Christian Heimes added the comment: This seems to be an asyncio problem. -- assignee: christian.heimes -> ___ Python tracker ___ _

[issue36709] Asyncio SSL keep-alive connections raise errors after loop close.

Andrew Svetlov added the comment: Sorry, I'm not comfortable with such change just before the feature freeze. The idea is maybe good but let's discuss and implement it later. -- ___ Python tracker __

[issue36709] Asyncio SSL keep-alive connections raise errors after loop close.

Yury Selivanov added the comment: > Not sure if we have to drop this warning, it enforces writing good code that > controls all created resources lifecycle. Right, maybe we add "transport.terminate()" as well? Synchronously & immediately closing a transport is a valid use case. TBH I don'

[issue36709] Asyncio SSL keep-alive connections raise errors after loop close.

Andrew Svetlov added the comment: It's not about streams only. The stream protocol can have such flag, sure. But transport emits a warning like "unclosed transport ..." Not sure if we have to drop this warning, it enforces writing good code that controls all created resources lifecycle. ---

[issue36709] Asyncio SSL keep-alive connections raise errors after loop close.

Yury Selivanov added the comment: > Sorry, that's how asyncio is designed. Andrew, couldn't we provide a "stream.terminate()" method (not a coroutine) that would do the following: * close the transport * set a flag in the protocol that the stream has been terminated. When the flag is set,

[issue36709] Asyncio SSL keep-alive connections raise errors after loop close.

Andrew Svetlov added the comment: The difference is that socket.close() is an instant call. After socket.close() the socket is done. But transport.close() doesn't close the transport instantly. asyncio requires at least one loop iteration for calling protocol.connection_lost() and actual socke

[issue36709] Asyncio SSL keep-alive connections raise errors after loop close.

Tom Christie added the comment: Right, and `requests` *does* provide both those styles. The point more being that *not* having closed the transport at the point of exit shouldn't end up raising a hard error. It doesn't raise errors in sync-land, and it shouldn't do so in async-land. Similar

[issue36709] Asyncio SSL keep-alive connections raise errors after loop close.

Andrew Svetlov added the comment: I would say that if requests a designed from scratch more idiomatic way could be with requests.Session() as session: session.get('https://example.com/') or session = requests.Session() session.get('https://example.com/') session.close() Like the recomme

[issue36709] Asyncio SSL keep-alive connections raise errors after loop close.

Tom Christie added the comment: > From my understanding, the correct code should close all transports and wait > for their connection_lost() callbacks before closing the loop. Ideally, yes, although we should be able to expect that an SSL connection that hasn't been gracefully closed wouldn'

[issue36709] Asyncio SSL keep-alive connections raise errors after loop close.

Andrew Svetlov added the comment: >From my understanding, the correct code should close all transports and wait >for their connection_lost() callbacks before closing the loop. -- ___ Python tracker

[issue36709] Asyncio SSL keep-alive connections raise errors after loop close.

Tom Christie added the comment: This appears somewhat related: https://bugs.python.org/issue34506 As it *also* logs exceptions occuring during `_fatal_error` and `_force_close`. -- ___ Python tracker __

[issue36709] Asyncio SSL keep-alive connections raise errors after loop close.

New submission from Tom Christie : If an asyncio SSL connection is left open (eg. any kind of keep-alive connection) then after closing the event loop, an exception will be raised... Python: ``` import asyncio import ssl import certifi async def f(): ssl_context = ssl.create_default_con