Bug: threading lock on cancellation

[chrisgoddard]

Describe the bug
Provide a clear and concise description of the bug.

Sometimes, when I cancel out of the faststream application, I get notification that the app has shutdown gracefully, but the cli itself does not exit and has to be cancelled again, so I get this error:

redis: 2024-09-13 09:32:42,680 - faststream.access.redis - MainThread - INFO     - Application was stopped
2024-09-13 09:32:42,709 INFO     - FastStream app shutting down...
2024-09-13 09:32:42,710 INFO     - FastStream app shut down gracefully.
^CException ignored in: <module 'threading' from '/Users/chrisgoddard/.local/share/uv/python/cpython-3.12.5-macos-aarch64-none/lib/python3.12/threading.py'>
Traceback (most recent call last):
  File "/Users/chrisgoddard/.local/share/uv/python/cpython-3.12.5-macos-aarch64-none/lib/python3.12/threading.py", line 1624, in _shutdown
    lock.acquire()
KeyboardInterrupt: 

It may be something in my own code that's causing this - but I'm not quite sure where to begin in tracking it down. Do you have any best practices on managing graceful shutdowns within a FastStream application? I'm using several async generators which have caused me problems in the past with not handling cancelation properly - I've tried passing around a threading.Event around all of the various generators and tasks to try to get them to all stop when any one fails but I'm still running into these issues.

Sorry if that's too vague - trying to describe the problem without having to paste my entire source into the issue!

[Lancetnik]

@chrisgoddard we are using threading module only in --reload CLI feature. Do you use it? If no - the problem should be in your code
Also, can you show your faststream using version (in all discussions and issues)?

We have a helpful option for graceful shoutdown Broker(graceful_timeout=30.0) - it waits for all running endpoints be done before stop, but it shouldn't help in your case...

[Lancetnik]

Sorry, but I have to close the Issue without activity