Handle graceful shtudown on SIGTERM for all binaries

[kariy]

ref: #2434

Summary by CodeRabbit

• New Features

  • Introduced a new module for handling operating system signals, enhancing the application's ability to manage shutdown procedures.
  • Implemented asynchronous signal handling for SIGINT and SIGTERM, allowing for more responsive application behavior during shutdowns.

• Bug Fixes

  • Improved the application's responsiveness by allowing it to handle signals concurrently with main operations.

• Documentation

  • Updated dependency configurations to support new signal handling features.

[coderabbitai]

Walkthrough

Ohayo, sensei! This pull request introduces significant changes to the signal handling mechanisms across multiple files. It removes the previous wait_signal and sigterm functions from the utils module and replaces them with a new wait_signals function in the dojo_utils::signal module. This update enhances the application's ability to handle OS signals like SIGINT and SIGTERM more effectively, improving the control flow in the main functions of various binaries to allow for graceful shutdowns.

Changes

Files	Change Summary
bin/katana/src/cli/node.rs	Removed wait_signal import; replaced with dojo_utils::signal::wait_signals() in the tokio::select! block.
bin/katana/src/utils.rs	Removed wait_signal and sigterm functions, eliminating previous signal handling logic.
bin/saya/src/main.rs	Modified main to use tokio::select! for concurrent handling of saya.start() and signals from dojo_utils::signal::wait_signals().
bin/torii/src/main.rs	Added an await for dojo_utils::signal::wait_signals() to handle system signals in the main function.
crates/dojo-utils/Cargo.toml	Updated tokio dependency to include "signal" feature; added rpassword to workspace section and removed duplicate entry.
crates/dojo-utils/src/lib.rs	Introduced a new public module signal.
crates/dojo-utils/src/signal.rs	Added wait_signals function for asynchronous signal handling; included a helper function sigterm for Unix systems.

Possibly related PRs

• opt(katana): graceful shutdown on critical tasks termination #2409: Enhances shutdown logic in node.rs to manage multiple shutdown triggers, related to signal handling updates.
• opt(katana): graceful shutdown on SIGTERM #2434: Implements a graceful shutdown mechanism upon receiving a SIGTERM signal, aligning with updates in node.rs and utils.rs.

Suggested labels

sozo

---

Recent review details

Configuration used: .coderabbit.yaml
Review profile: CHILL

Commits

Files that changed from the base of the PR and between 435c2d1 and cf0c10a.

Files selected for processing (7)

• bin/katana/src/cli/node.rs (2 hunks)
• bin/katana/src/utils.rs (0 hunks)
• bin/saya/src/main.rs (1 hunks)
• bin/torii/src/main.rs (1 hunks)
• crates/dojo-utils/Cargo.toml (1 hunks)
• crates/dojo-utils/src/lib.rs (1 hunks)
• crates/dojo-utils/src/signal.rs (1 hunks)

Files not reviewed due to no reviewable changes (1)

• bin/katana/src/utils.rs

Additional comments not posted (9)

crates/dojo-utils/src/lib.rs (1)

11-12: Ohayo sensei! 🌅

LGTM! The addition of the signal module looks good. 👍

Just a friendly reminder to ensure that the module is well-documented and follows our established coding conventions and best practices. This will help maintain consistency and make it easier for other senseis to understand and use the new functionality.

crates/dojo-utils/Cargo.toml (2)

12-12: Ohayo sensei! The rpassword dependency addition looks good.

Adding rpassword to the workspace section is the right way to manage the dependency at the workspace level. This change is consistent with the workspace configuration and follows best practices.

---

15-15: Ohayo sensei! The tokio dependency update is spot on.

Adding the "signal" feature to the tokio dependency is essential for enabling the functionality related to asynchronous signal handling. This change aligns perfectly with the PR objective of handling graceful shutdown on SIGTERM for all binaries.

Also, setting default-features to false is a good practice to ensure that only the explicitly specified features are enabled, avoiding unnecessary dependencies.

crates/dojo-utils/src/signal.rs (2)

8-19: Ohayo sensei! 🙇‍♂️

LGTM! The wait_signals function looks great! 👍

It correctly uses conditional compilation to handle different OS signals based on the platform. The tokio::select! macro is the perfect choice for concurrently awaiting multiple async operations. The code is clean, idiomatic, and follows best practices. 🌟

Excellent work! 🎉

---

23-27: Ohayo sensei! 🙇‍♂️

Nicely done! The sigterm function is implemented perfectly! 💯

It correctly uses the tokio::signal::unix module to register a listener for the SIGTERM signal on Unix systems. Returning a Result type is a good practice to handle any potential errors. The code is concise, readable, and follows the Unix-specific conventions. 🚀

Keep up the great work! 😊

bin/saya/src/main.rs (1)

23-26: Ohayo sensei! 🌞

LGTM! The use of tokio::select! to concurrently handle saya.start() and dojo_utils::signal::wait_signals() is a great improvement. It allows the program to handle the shutdown process more gracefully while still running its main functionality. The logic and syntax look solid. 👍

This change enhances the responsiveness of the application. Nice work sensei! 🙌

bin/torii/src/main.rs (1)

273-273: Ohayo sensei! This change looks great! 👍

Awaiting dojo_utils::signal::wait_signals() will allow the application to handle system signals gracefully, improving its robustness. The control flow modification in the main function to include this operation is spot on.

bin/katana/src/cli/node.rs (2)

41-41: Ohayo sensei! The import removal looks good.

The removal of the wait_signal import is a valid refactoring, as it's no longer being used in this file due to the changes in the tokio::select! block.

---

238-238: Ohayo sensei! The signal handling refactor looks good.

The change to use dojo_utils::signal::wait_signals() instead of wait_signal is a valid refactoring. It suggests a move towards a more centralized and standardized approach for signal handling within the application. The control flow remains intact, only the underlying implementation for waiting on signals has been updated.

To verify that the new dojo_utils::signal::wait_signals() function is being used correctly across the codebase, you can run the following script:

Verification successful

---

Ohayo sensei! The signal handling refactor is on point across the codebase.

The verification process confirms that the new dojo_utils::signal::wait_signals() function is being used consistently in all relevant parts of the codebase. The old wait_signal function has been completely replaced, and there are no lingering instances of the previous implementation.

• The new function is used in bin/torii/src/main.rs, bin/saya/src/main.rs, and bin/katana/src/cli/node.rs
• The function is properly defined in crates/dojo-utils/src/signal.rs

This refactoring has successfully standardized the signal handling approach across the application.

Scripts executed

The following scripts were executed for the analysis:

Script:

#!/bin/bash
# Description: Verify `dojo_utils::signal::wait_signals()` usage across the codebase.

# Test: Search for the function usage. 
# Expect: Only occurrences of the new function, no occurrences of the old `wait_signal` function.
rg --type rust $'dojo_utils::signal::wait_signals\(\)'

# Test: Search for the old function usage.
# Expect: No occurrences of the old `wait_signal` function.
rg --type rust $'wait_signal'

Length of output: 616

---

Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  -- I pushed a fix in commit <commit_id>, please review it.
  -- Generate unit testing code for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  -- @coderabbitai generate unit testing code for this file.
  -- @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  -- @coderabbitai generate interesting stats about this repository and render them as a table.
  -- @coderabbitai read src/utils.ts and generate unit testing code.
  -- @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.
  -- @coderabbitai help me debug CodeRabbit configuration file.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (Invoked using PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai full review to do a full review from scratch and review all the files again.
• @coderabbitai summary to regenerate the summary of the PR.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai configuration to show the current CodeRabbit configuration for the repository.
• @coderabbitai help to get help.

Other keywords and placeholders

• Add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.
• Add @coderabbitai summary to generate the high-level summary at a specific location in the PR description.
• Add @coderabbitai anywhere in the PR title to generate the title automatically.

Documentation and Community

• Visit our Documentation for detailed information on how to use CodeRabbit.
• Join our Discord Community to get help, request features, and share feedback.
• Follow us on X/Twitter for updates and announcements.

[glihm]

Great to have this moved to dojo utils. 👍

[codecov]

Codecov Report

Attention: Patch coverage is 0% with 12 lines in your changes missing coverage. Please review.

Project coverage is 68.19%. Comparing base (f4e15f1) to head (cf0c10a).
Report is 3 commits behind head on main.

Files with missing lines	Patch %	Lines
crates/dojo-utils/src/signal.rs	0.00%	7 Missing ⚠️
bin/saya/src/main.rs	0.00%	4 Missing ⚠️
bin/torii/src/main.rs	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #2435      +/-   ##
==========================================
+ Coverage   68.04%   68.19%   +0.15%     
==========================================
  Files         364      365       +1     
  Lines       47871    47873       +2     
==========================================
+ Hits        32573    32647      +74     
+ Misses      15298    15226      -72     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.