You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This error is also raised when the timer context is used within a task, but that task is on a different event loop to the one the ClientSession was created with because it uses asyncio.current_task(loop=self._loop). Calling asyncio.current_task() would show there is a task, but not on the correct event loop.
To Reproduce
This stripped down example is a bit convoluted, but is the least amount of code I could come up with to reproduce what my application does. It has a long running context and spins up an event loop in another thread, which tries to use the session. Now that I have realised the problem have plans to change this entirely, but I thought it would be worth reporting as I think the error could be clearer.
The error could make it clear that this error could also occur if the task was created on the wrong event loop and not just that the timeout manager was not used inside a task. Or possibly it could distinguish the two cases and give different errors.
Logs/tracebacks
This loop
Status: 200Content-type: text/html; charset=utf-8Body: <!doctype html> ...
Wrong loop
Task exception was never retrieved
future: <Task finished name='Task-7' coro=<main.<locals>.get() done, defined at /workspaces/fastcs-eiger/app.py:10> exception=RuntimeError('Timeout context manager should be used inside a task')>
Traceback (most recent call last):
File "/workspaces/fastcs-eiger/app.py", line 11, in getasyncwith session.get("http://python.org") as response:
File "/venv/lib/python3.11/site-packages/aiohttp/client.py", line 1423, in __aenter__self._resp: _RetType =awaitself._coro
^^^^^^^^^^^^^^^^
File "/venv/lib/python3.11/site-packages/aiohttp/client.py", line 607, in _requestwith timer:
File "/venv/lib/python3.11/site-packages/aiohttp/helpers.py", line 636, in __enter__raiseRuntimeError("Timeout context manager should be used inside a task")
RuntimeError: Timeout context manager should be used inside a task
Unclosed client session
client_session: <aiohttp.client.ClientSession object at 0x7efc90fd9f50>
Unclosed connector
connections: ['deque([(<aiohttp.client_proto.ResponseHandler object at 0x7efc90e08910>, 115561.676192066)])']connector: <aiohttp.connector.TCPConnector object at 0x7efc90e02110>
I feel like running multiple event loops is not a typical or recommended practice, so if you are doing this, you'd probably need to be aware of these sort of issues anyway. If you have a suggestion for a better message that won't confuse typical users with a single loop (and possibly not even knowing what the loop is), then feel free to open a PR changing it.
Yeah, it's a tricky one. If you want to keep the message simple for the common case, distinct errors would probably be best:
task=asyncio.current_task(loop=self._loop)
iftaskisNone:
ifasyncio.current_task() isnotNone:
raiseRuntimeError("Timeout context manager used in a task running on a different event loop")
else:
raiseRuntimeError("Timeout context manager should be used inside a task")
Then the error mentioning event loops shouldn't occur if there is only a single event loop.
If you think this is reasonable I can put in a PR, but also I understand that this may not be worth changing.
Describe the bug
This error is also raised when the timer context is used within a task, but that task is on a different event loop to the one the
ClientSession
was created with because it usesasyncio.current_task(loop=self._loop)
. Callingasyncio.current_task()
would show there is a task, but not on the correct event loop.To Reproduce
This stripped down example is a bit convoluted, but is the least amount of code I could come up with to reproduce what my application does. It has a long running context and spins up an event loop in another thread, which tries to use the session. Now that I have realised the problem have plans to change this entirely, but I thought it would be worth reporting as I think the error could be clearer.
Expected behavior
The error could make it clear that this error could also occur if the task was created on the wrong event loop and not just that the timeout manager was not used inside a task. Or possibly it could distinguish the two cases and give different errors.
Logs/tracebacks
Python Version
aiohttp Version
multidict Version
propcache Version
yarl Version
OS
RHEL8
Related component
Client
Additional context
No response
Code of Conduct
The text was updated successfully, but these errors were encountered: