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
Currently, when shutting down the main server loop, the vectored launcher/custom join_all which is called in
main->crate::util::tasks::join_all() does not properly/fully exit upon SIGINT/SIGTERM.
This results in a partial or “hung” shutdown state that never actually completes.
Implementing a graceful shutdown handler will ensure the primary server loop and all the child services quit cleanly once the shutdown future completes.
This is the recommended approach by Axum/Tokio for shutdowns from what I understand.
If there's a reason I've missed (Perhaps something to do with the Messenger) then please clarify for me so I can understand the intention.
Why It’s Needed
Provides a more reliable and consistent shutdown flow.
Prevents lingering resources or partial states when stopping the application.
Aligns behavior with best practices for asynchronous service shutdown.
Proposed Fix
Add a graceful shutdown handler that triggers on service stop signals (e.g., SIGINT, SIGTERM).
Update the vectored launcher to correctly exit after the shutdown future completes.
Acceptance Criteria
Server resources/clients stop and release resources properly when a shutdown signal is triggered.
Vectored launcher cleanly terminates without leaving any dangling tasks
No observable hangs or partial shutdown states.
A pull request (PR) referencing this issue will be opened shortly to implement the above changes.
The text was updated successfully, but these errors were encountered:
Description
Currently, when shutting down the main server loop, the vectored launcher/custom join_all which is called in
main->
crate::util::tasks::join_all()
does not properly/fully exit upon SIGINT/SIGTERM.This results in a partial or “hung” shutdown state that never actually completes.
Implementing a graceful shutdown handler will ensure the primary server loop and all the child services quit cleanly once the shutdown future completes.
This is the recommended approach by Axum/Tokio for shutdowns from what I understand.
If there's a reason I've missed (Perhaps something to do with the Messenger) then please clarify for me so I can understand the intention.
Why It’s Needed
Proposed Fix
Acceptance Criteria
A pull request (PR) referencing this issue will be opened shortly to implement the above changes.
The text was updated successfully, but these errors were encountered: