Use get_event_loop at call-site when not set

[u8sand]

Maybe you have a better idea of how to fix this but the newer version of aiohttp gives me this error:

RuntimeError: Task <Task pending name='Task-21' coro=<RequestHandler._handle_request() running at /home/u8sand/.local/lib/python3.10/site-packages/aiohttp/web_protocol.py:435> cb=[Task.task_wakeup()]> got Future <Future pending cb=[_chain_future.<locals>._call_check_cancel() at /usr/lib/python3.10/asyncio/futures.py:384]> attached to a different loop
INFO:aiohttp.access:127.0.0.1 [15/Feb/2022:14:52:50 +0000] "GET / HTTP/1.1" 302 199 "-" "Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/98.0.4758.80 Safari/537.36"
Traceback (most recent call last):
  File "/home/u8sand/Programs/work/active/appyter/appyter/render/flask_app/__init__.py", line 59, in error_handler
    return await handler(request)
  File "/home/u8sand/.local/lib/python3.10/site-packages/aiohttp/web_urldispatcher.py", line 197, in handler_wrapper
    return await result
  File "/home/u8sand/.local/lib/python3.10/site-packages/aiohttp_wsgi/wsgi.py", line 294, in handle_request
    return await self._loop.run_in_executor(

I assume this means that somehow aiohttp is using a different event loop during request handling. The easiest way I found to fix this was just to use asyncio.get_event_loop() in the request handler, rather than running it at initialization. I opted to preserve the loop option and use it if explicitly specified but fall back to determining the loop at the call-site. This should preserve backwards compatibility while fixing this particular issue.

[etianen]

I think the solution here is to not store self._loop and all and use asyncio.get_running_loop().

What do you think?

[u8sand]

@etianen I considered that but I wasn't sure if there are people that use the loop argument with some specific event loop that is not the same as the one you get from asyncio.get_running_loop() this approach (preserving the loop argument) might be less likely to break the aforementioned edge-case.

I personally never carry around a reference to the event loop in my own code (opting instead for asyncio.get_running_loop()) so I can certainly remove this argument if you'd prefer :+1: .

[etianen]

Yeah, I reckon lose the reference. I can't think of a reason to support that edge case.

On Fri, 18 Feb 2022 at 14:54, Daniel Clarke @.***> wrote:

@etianen https://github.com/etianen I considered that but I wasn't sure if there are people that use the loop argument with some specific event loop that is not the same as the one you get from asyncio.get_running_loop() this approach (preserving the loop argument) might be less likely to break the aforementioned edge-case.

I personally never carry around a reference to the event loop in my own code (opting instead for asyncio.get_running_loop()) so I can certainly remove this argument if you'd prefer 👍 .

— Reply to this email directly, view it on GitHub https://github.com/etianen/aiohttp-wsgi/pull/34#issuecomment-1044649812, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABEKCEISEXX73DEUJCH7X3U3ZMRPANCNFSM5OOYWLQQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[etianen]

Thanks!