[PLA-2066] Tokio task would panic depend on the error

[leonardocustodio]

PR Type

enhancement, bug fix

---

Description

• Improved error handling in runtime_subscription and block_subscription methods by removing unwrap calls and adjusting logic to prevent panics.
• Corrected formatting in Cargo.toml by adding a missing comma in the tokio dependency features list.
• Simplified docker-compose.yml by removing the version specification.

---

Changes walkthrough 📝

	Relevant files
Bug fix	subscription.rs Improve error handling in subscription methods                      src/subscription.rs Removed unwrap calls from async functions to prevent panics. Eliminated error return types from runtime_subscription and block_subscription. Adjusted error handling logic to continue on certain errors instead of returning. +6/-16
Formatting	Cargo.toml Correct formatting in Cargo.toml dependencies                        Cargo.toml Fixed formatting by adding a comma in the tokio dependency features list. +1/-1
Configuration changes	docker-compose.yml Simplify docker-compose configuration by removing version docker-compose.yml Removed the version specification from the docker-compose file. +0/-2

---

💡 PR-Agent usage: Comment /help "your question" on any pull request to receive relevant information

[github-actions]

PR Reviewer Guide 🔍

Here are some key observations to aid the review process:

⏱️ Estimated effort to review: 3 🔵🔵🔵⚪⚪

🧪 No relevant tests

🔒 No security concerns identified

⚡ Recommended focus areas for review Error Handling The use of unwrap in asynchronous functions runtime_subscription and block_subscription could lead to panics if the awaited values result in errors. Consider implementing proper error handling to avoid potential runtime panics. Loop Control The continue statement in the error handling block of block_subscription might lead to infinite loops if the error persists. It's important to ensure that there are mechanisms to break out of the loop or handle errors more robustly.

[github-actions]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Score
Possible bug	Improve error handling by replacing unwrap() with proper error checking and logging Handle potential errors from updater.runtime_updates().await instead of unwrapping directly to avoid panics in case of errors. src/subscription.rs [40] -let mut update_stream = updater.runtime_updates().await.unwrap(); +let mut update_stream = match updater.runtime_updates().await { + Ok(stream) => stream, + Err(e) => { + tracing::error!("Failed to get runtime updates: {:?}", e); + return; + } +}; Suggestion importance[1-10]: 8 Why: This suggestion correctly identifies a potential source of runtime panic due to the use of unwrap() and provides a safer alternative by handling possible errors gracefully. This enhances the robustness of the code.	8
	Enhance robustness by handling errors during block subscription instead of using unwrap() Replace the unwrap() call with error handling when subscribing to finalized blocks to prevent potential panics. src/subscription.rs [73] -let mut blocks_sub = self.rpc.blocks().subscribe_finalized().await.unwrap(); +let mut blocks_sub = match self.rpc.blocks().subscribe_finalized().await { + Ok(sub) => sub, + Err(e) => { + tracing::error!("Failed to subscribe to finalized blocks: {:?}", e); + return; + } +}; Suggestion importance[1-10]: 8 Why: Similar to the first suggestion, this one addresses the use of unwrap() which can lead to panics. The suggested error handling improves the application's stability and error reporting.	8
Enhancement	Improve thread safety and error handling in the locking mechanism for block_header Use a more robust locking mechanism or handle potential panics when locking block_header to improve thread safety. src/subscription.rs [93] -let mut block_header = self.block_header.lock().unwrap(); +let mut block_header = match self.block_header.lock() { + Ok(lock) => lock, + Err(e) => { + tracing::error!("Failed to lock block_header: {:?}", e); + return; + } +}; Suggestion importance[1-10]: 7 Why: This suggestion addresses a common issue with multithreading where unwrap() on a lock might panic if the mutex is poisoned. The improved code handles this scenario gracefully, enhancing the thread safety and reliability of the code.	7
	Add error logging for non-reconnection related errors in block subscription Ensure that the error handling logic for block in the block_subscription method logs the error details before continuing. src/subscription.rs [78-83] Err(e) => { if e.is_disconnected_will_reconnect() { tracing::warn!("Lost connection with the RPC node, reconnecting..."); + } else { + tracing::error!("Error receiving block: {:?}", e); } continue; } Suggestion importance[1-10]: 6 Why: This suggestion adds valuable error logging for cases where the error is not related to a disconnection that will reconnect. It enhances the error handling by providing more detailed diagnostics.	6