Uvicorn >= 0.29.0 doesn't terminate if other threads have been started

[Lego3]

I tried to update to the latest version of uvicorn, coming from a version < 0.29.0, and now my app doesn't close on SIGINT anymore. I found the issue #2289 which has supposedly been fixed in 0.30.0 and is thus closed, but just like the latest commenter I have issues also in the latest version.

Here is a small example:

import signal
import threading
import time
import uvicorn


ADD_SIGNAL_HANDLER = True


stop_the_extra_thread = threading.Event()

def function_running_in_thread():
    while not stop_the_extra_thread.is_set():
        time.sleep(0.1)


if __name__ == "__main__":
    server_conf = uvicorn.Config(None, host="127.0.0.1", port=8000)
    server = uvicorn.Server(server_conf)

    thread = threading.Thread(target=function_running_in_thread)
    thread.start()

    def stop_on_signal(_signal, _frame):
        pass

    if ADD_SIGNAL_HANDLER:
        signal.signal(signal.SIGINT, stop_on_signal)

    server.run()

    stop_the_extra_thread.set()

When using uvicorn < 0.29.0 it doesn't matter whether ADD_SIGNAL_HANDLER is True or False. I always get the same behaviour that the server.run() ends fine, and my own thread also ends.

On uvicorn >= 0.29.0, however, when ADD_SIGNAL_HANDLER is True everything works just like on the earlier versions, but when it is False the output is instead:

INFO:     Started server process [54982]
INFO:     Waiting for application startup.
INFO:     ASGI 'lifespan' protocol appears unsupported.
INFO:     Application startup complete.
INFO:     Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)
^CINFO:     Shutting down
INFO:     Finished server process [54982]
Traceback (most recent call last):
  File "/usr/lib/python3.11/asyncio/runners.py", line 118, in run
    return self._loop.run_until_complete(task)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/asyncio/base_events.py", line 654, in run_until_complete
    return future.result()
           ^^^^^^^^^^^^^^^
asyncio.exceptions.CancelledError

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/home/elinge/workspaces/gitlab/sbs-artifact-service/test.py", line 30, in <module>
    server.run()
  File "/home/elinge/workspaces/gitlab/sbs-artifact-service/.venv/lib/python3.11/site-packages/uvicorn/server.py", line 66, in run
    return asyncio.run(self.serve(sockets=sockets))
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/asyncio/runners.py", line 190, in run
    return runner.run(main)
           ^^^^^^^^^^^^^^^^
  File "/usr/lib/python3.11/asyncio/runners.py", line 123, in run
    raise KeyboardInterrupt()
KeyboardInterrupt
^CException ignored in: <module 'threading' from '/usr/lib/python3.11/threading.py'>
Traceback (most recent call last):
  File "/usr/lib/python3.11/threading.py", line 1590, in _shutdown
    lock.acquire()
KeyboardInterrupt: 

After this it hangs, and I have to do another Ctrl+C to be able to exit.

I would argue this is still a bug that needs to be fixed.

[maxfischer2781]

This was an intentional change to allow programs to react to SIGINT. Your program could be easily fixed if stop_on_signal would, well, stop on signal (by setting the event you have prepared). You can also catch-and-handle the exception. While this requires adjustments of some programs, it enables writing programs that were impossible to have before.

But frankly I am getting more and more the impression that a true programmatic usage is not desired, but rather that people expect every single entry point to behave like the broken CLI that uvicorn was before. So instead of discussing this endlessly and calling things „bug" that frankly most don’t understand:
I recommend people just vote whether usecases like mine, which require not swallowing signals, are in scope. I’ll happily rip out the required changes and let you people reinvent the wheel in peace if you want to.

[Lego3]

It seems I struck a nerve here, and for that I am truly sorry. I haven't followed previous conversations (if any), only the linked issue. My usage of uvicorn is quite simple, and I just observed an unexpected change in behaviour and when I investigated it turned out to look like an issue.

You are of course entirely correct. I implicitly expected uvicorn to swallow all KeyboardInterrupts (which it did before), and I suppose what made me confused when trying to adapt in this case is that now it only sometimes gives KeyboardInterrupt. I.e. if I do register a signal handler, then uvicorn no longer throws the KeyboardInterrupt. I don't know much about signal handling best practices, and maybe that is a best practice? "Default" is to bubble the interrupt, but if I register a handler then it is assumed that I will handle everything separately?