refactor(ethexe/node-loader): simplify process_events loop and watch promises from injected messages

[playX18]

@gear-tech/dev

[semanticdiff-com]

Review changes with  

Changed Files

File	Status
ethexe/node-loader/src/batch/rpc_pool.rs	62% smaller
ethexe/node-loader/src/batch.rs	18% smaller
ethexe/node-loader/src/utils.rs	8% smaller

[gemini-code-assist]

Summary of Changes

Hello, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refactors the node-loader's event processing logic to better support injected transactions. By leveraging promise-based replies for injected messages, the system can now resolve outcomes more efficiently. Additionally, the change cleans up event parsing by removing unnecessary statistics tracking and streamlining the logging infrastructure for better performance and clarity.

Highlights

• Injected Message Handling: Refactored the injected message flow to use send_message_injected_and_watch, which returns a Promise containing the reply result, allowing for immediate processing without waiting for chain events.
• Event Processing Loop: Simplified the process_events loop by removing redundant ProcessEventsStats tracking and consolidating logic for handling both injected promises and regular chain events.
• Tracing Improvements: Updated numerous tracing::debug! calls to tracing::trace! and improved structured logging to reduce noise while maintaining essential diagnostic information.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request refactors the batch processing logic in the node loader to improve efficiency and logging. Key changes include the integration of Promise handling for injected transactions, which allows for immediate resolution of message statuses from RPC responses, and the removal of the ProcessEventsStats and BlockProcessStats tracking structures. Additionally, the PR transitions to structured logging and renames RPC methods to better reflect their functionality. A critical logic error was identified in the process_events function where a successful message outcome from mirror logs could be incorrectly overwritten by an error status from router transitions; a fix was suggested to ensure the more canonical source of truth is preserved.

[gemini-code-assist]

This logic incorrectly overwrites a successful outcome from mirror logs with an error from router transitions. If mirror logs indicate a message was successful (*entry is None), but transitions indicate an error (status is Some(error)), the success status is replaced by the error. This can lead to incorrect reporting of batch outcomes. It's safer to trust the mirror logs as the more canonical source of truth. Note that per repository guidelines, logging of this discrepancy should be handled by the outer processor rather than at this call site to avoid duplication.

Suggested change

	(None, Some(_)) => *entry = status,
	(None, Some(_)) => {},

References

1. Error handling, such as logging, can be centralized in an outer component (e.g., an 'outer processor') rather than being duplicated at every call site.