Added Python 3.12 support.

[felixxm]

No description provided.

[felixxm]

Waiting for #413 #414.

[andrewgodwin]

Looks good to me code-wise, we're good to merge if the rebase onto #414 gets everything passing.

[felixxm]

Great, all 🟢 I still have some warnings to investigate:

Task was destroyed but it is pending!
task: <Task pending name='Task-30' coro=<StatelessServer.application_checker() running at /home/runner/work/asgiref/asgiref/asgiref/server.py:136> wait_for=<Future pending cb=[Task.task_wakeup()]>>
Task was destroyed but it is pending!
task: <Task cancelling name='Task-42' coro=<server.<locals>.app() running at /home/runner/work/asgiref/asgiref/tests/test_server.py:81> wait_for=<Future cancelled>>
Task was destroyed but it is pending!
task: <Task cancelling name='Task-43' coro=<server.<locals>.app() running at /home/runner/work/asgiref/asgiref/tests/test_server.py:81> wait_for=<Future cancelled>>
Task was destroyed but it is pending!
task: <Task cancelling name='Task-44' coro=<server.<locals>.app() running at /home/runner/work/asgiref/asgiref/tests/test_server.py:81> wait_for=<Future cancelled>>
Task was destroyed but it is pending!
task: <Task cancelling name='Task-45' coro=<server.<locals>.app() running at /home/runner/work/asgiref/asgiref/tests/test_server.py:81> wait_for=<Future cancelled>>
Task was destroyed but it is pending!
task: <Task cancelling name='Task-46' coro=<server.<locals>.app() running at /home/runner/work/asgiref/asgiref/tests/test_server.py:81> wait_for=<Future cancelled>>
Task was destroyed but it is pending!
task: <Task cancelling name='Task-47' coro=<server.<locals>.app() running at /home/runner/work/asgiref/asgiref/tests/test_server.py:81> wait_for=<Future cancelled>>
Task was destroyed but it is pending!
task: <Task cancelling name='Task-48' coro=<server.<locals>.app() running at /home/runner/work/asgiref/asgiref/tests/test_server.py:81> wait_for=<Future cancelled>>
Task was destroyed but it is pending!
task: <Task cancelling name='Task-49' coro=<server.<locals>.app() running at /home/runner/work/asgiref/asgiref/tests/test_server.py:81> wait_for=<Future cancelled>>
Task was destroyed but it is pending!
task: <Task cancelling name='Task-50' coro=<server.<locals>.app() running at /home/runner/work/asgiref/asgiref/tests/test_server.py:81> wait_for=<Future cancelled>>
Task was destroyed but it is pending!
task: <Task cancelling name='Task-51' coro=<server.<locals>.app() running at /home/runner/work/asgiref/asgiref/tests/test_server.py:81> wait_for=<Future cancelled>>
Task was destroyed but it is pending!
task: <Task cancelling name='Task-52' coro=<server.<locals>.app() running at /home/runner/work/asgiref/asgiref/tests/test_server.py:81> wait_for=<Future cancelled>>

[felixxm]

Great, all 🟢 I still have some warnings to investigate:

Warning are caused by future for application_instances. Adding cancel() for not done tasks in application_checker() fixes warnings, but that's of course not a solution:

diff --git a/asgiref/server.py b/asgiref/server.py
index 43c28c6..ae81150 100644
--- a/asgiref/server.py
+++ b/asgiref/server.py
@@ -144,6 +144,8 @@ class StatelessServer:
                     except KeyError:
                         # Exception handling might have already got here before us. That's fine.
                         pass
+                else:
+                    details["future"].cancel()
 
     async def application_exception(self, exception, application_details):
         """

I'd like to be more fluent in asyncio 😞

[carltongibson]

<Task cancelling ...

There's an error in the Server code here...

        server.run()
>       assert loop.is_running()
E       assert False

The run_until_complete in Server.run() is shutting the event-loop when handle() exits, and so the futures, whilst cancelled in server.close() (called by the pytest fixture at the end of the test) never get a chance on the event loop to actually cancel. (details["future"].cancelled() never becomes True)

[carltongibson]

FWIW I don't think this is a PY312 issue.

[andrewgodwin]

Yeah I think that's been there for a while. Happy to fix it as part of this PR or we can work on it separately.

[felixxm]

TBH, I don't know how to fix it (and I really tried), so it'd be great if we can do it separately.

[andrewgodwin]

Yes, that is almost certainly why I did not get it fixed before; there's a whole range of issues like this that only really arise in the CI scenario when things are being rapidly created and deleted.