chore: improve spans and logs

[carneiro-cw]

No description provided.

[github-actions]

PR Reviewer Guide 🔍

⏱️ Estimated effort to review [1-5]	2
🧪 Relevant tests	No
🔒 Security concerns	No
⚡ Key issues to review	Logging Level Change: The logging level has been changed from debug to info. Ensure this change aligns with the intended verbosity and does not expose sensitive information in production logs.
	Span Handling: The PR replaces direct span manipulation with Span::with(...). Verify that this change correctly maintains the span context across asynchronous tasks.

[github-actions]

PR Code Suggestions ✨

Category	Suggestion	Score
Enhancement	Implement a retry mechanism for transaction sending to enhance robustness Consider adding a retry mechanism or a circuit breaker to handle repeated failures in the send_raw_transaction method, enhancing the robustness of the transaction sending process. src/eth/relayer/external.rs [248] -tracing::warn!(?tx_hash, ?err, "failed to send raw transaction, retrying..."); +if retry_count < MAX_RETRY_LIMIT { + tracing::warn!(?tx_hash, ?err, "failed to send raw transaction, retrying..."); + retry_count += 1; +} else { + tracing::error!(?tx_hash, ?err, "exceeded maximum retry limit for sending transaction"); + return Err(err); +} Suggestion importance[1-10]: 10 Why: Implementing a retry mechanism significantly enhances the robustness and reliability of the transaction sending process, addressing potential repeated failures effectively.	10
	Enhance the structure and clarity of logging for transaction failures Use structured logging for the error context in the tracing::warn call to improve the readability and utility of log messages, especially when debugging issues related to transaction failures. src/eth/relayer/external.rs [248] -tracing::warn!(?tx_hash, ?err, "failed to send raw transaction, retrying..."); +tracing::warn!(error = ?err, tx_hash = ?tx_hash, "failed to send raw transaction, retrying..."); Suggestion importance[1-10]: 8 Why: Structured logging improves the clarity and utility of log messages, which is beneficial for debugging and maintaining the code.	8
Possible bug	Improve error handling in the transaction fetch operation Consider handling the unwrap_or(None) more safely by explicitly handling the error case instead of using unwrap_or. This can prevent potential runtime panics if the fetch_transaction method fails unexpectedly. src/eth/relayer/external.rs [244] -if self.substrate_chain.fetch_transaction(tx_hash).await.unwrap_or(None).is_some() { +if let Ok(Some(_)) = self.substrate_chain.fetch_transaction(tx_hash).await { Suggestion importance[1-10]: 9 Why: This suggestion enhances error handling, reducing the risk of runtime panics, which is crucial for the robustness and reliability of the code.	9
Maintainability	Replace Span::with with Span::current() to ensure consistent span handling Replace the Span::with closure with direct usage of Span::current() to maintain consistency with the existing span handling pattern in the codebase. This ensures that the span context is preserved correctly across asynchronous boundaries. src/eth/relayer/external.rs [90] -Span::with(|s| s.rec_str("block_number", &block_number)); +let span = Span::current(); +span.rec_str("block_number", &block_number); Suggestion importance[1-10]: 7 Why: The suggestion improves code consistency and maintainability by aligning with the existing span handling pattern. However, it does not address a critical issue or bug.	7