feat: fix parallel execution

[dinhani-cw]

No description provided.

[github-actions]

PR Review

⏱️ Estimated effort to review [1-5]	4, because the PR involves complex logic related to parallel execution in a blockchain context, which requires a deep understanding of concurrency, blockchain state management, and error handling.
🧪 Relevant tests	No
🔍 Possible issues	Possible Bug: The removal of prev_execution and the new logic to check conflicts with all previous transactions might significantly degrade performance due to increased complexity and repeated checks.
	Possible Inefficiency: The current implementation does not utilize temporary storage for conflict detection, which is noted with a TODO comment. Implementing this could improve performance by reducing the need for extensive conflict checks.
🔒 Security concerns	No

Code feedback:

---

relevant file	src/eth/executor.rs
suggestion	Consider implementing the conflict detection directly within the temporary storage as noted in the TODO comment. This would potentially reduce the overhead of checking each transaction against all previous ones, improving the efficiency of the parallel execution process. [important]
relevant line	// TODO: conflict detection in the temporary storage will avoid checking conflict with all previous transactions here

---

relevant file	src/eth/executor.rs
suggestion	To optimize the conflict checking loop, consider breaking out of the loop immediately after setting reexecute to true, instead of using an additional break statement. This minor change can improve the clarity and performance of the loop. [medium]
relevant line	reexecute = true;

---

relevant file	src/eth/executor.rs
suggestion	Add detailed logging for each step of the decision-making process in the parallel execution path, especially before re-executing a transaction. This will help in debugging and understanding the flow of transaction processing in production. [important]
relevant line	ParallelExecutionDecision::Reexecute(tx, receipt)

---

relevant file	src/eth/executor.rs
suggestion	Consider adding metrics or performance counters to monitor the number of re-executions and conflicts detected during parallel processing. This could be valuable for performance tuning and operational monitoring. [important]
relevant line	ParallelExecutionDecision::Reexecute(tx, receipt)

---

---

✨ Review tool usage guide:

---

Overview:
The review tool scans the PR code changes, and generates a PR review which includes several types of feedbacks, such as possible PR issues, security threats and relevant test in the PR. More feedbacks can be added by configuring the tool.

The tool can be triggered automatically every time a new PR is opened, or can be invoked manually by commenting on any PR.

• When commenting, to edit configurations related to the review tool (pr_reviewer section), use the following template:

/review --pr_reviewer.some_config1=... --pr_reviewer.some_config2=...

• With a configuration file, use the following template:

[pr_reviewer]
some_config1=...
some_config2=...

See the review usage page for a comprehensive guide on using this tool.

[github-actions]

PR Code Suggestions

Category	Suggestions
Enhancement	Simplify the match statement using if let for the Ok variant. Consider using if let to simplify the match arm that only deals with the Ok variant of evm_result. This can make the code more readable and concise. src/eth/executor.rs [163-165] -let decision = match evm_result { - (tx, receipt, Ok(evm_result)) => { - let current_execution = &evm_result.execution; +if let (tx, receipt, Ok(evm_result)) = evm_result { + let current_execution = &evm_result.execution;
	Use iterators and any() for conflict detection to simplify and optimize the code. Replace the manual loop for conflict checking with a more functional approach using iterators and any(), which can improve readability and performance. src/eth/executor.rs [171-178] -for prev_execution in &executions { +let reexecute = executions.iter().any(|prev_execution| { let prev_execution = &prev_execution.evm_result.execution; if let Some(conflicts) = prev_execution.check_conflicts(current_execution) { tracing::warn!(?conflicts, "parallel execution conflicts"); - reexecute = true; - break; + true + } else { + false } -} +});
	Use find_map for more efficient and readable conflict checking. Instead of manually setting and checking reexecute, use the find_map method to directly return when a conflict is found, improving efficiency and readability. src/eth/executor.rs [169-178] -let mut reexecute = false; -for prev_execution in &executions { +let reexecute = executions.iter().find_map(|prev_execution| { let prev_execution = &prev_execution.evm_result.execution; - if let Some(conflicts) = prev_execution.check_conflicts(current_execution) { + prev_execution.check_conflicts(current_execution).map(|conflicts| { tracing::warn!(?conflicts, "parallel execution conflicts"); - reexecute = true; - break; - } -} + true + }) +}).unwrap_or(false);
	Enhance error handling in the match statement for execution failures. Implement error handling for the Err(e) case in the match statement to ensure that errors are not only logged but also handled appropriately. src/eth/executor.rs [187-189] (tx, receipt, Err(e)) => { - tracing::warn!(reason = ?e, "parallel execution failed"); + tracing::error!(reason = ?e, "parallel execution failed"); + // Implement additional error handling logic here ParallelExecutionDecision::Reexecute(tx, receipt) }
Possible issue	Handle potential None from next() to prevent runtime panics. To avoid unwrapping directly which might cause a panic if next() returns None, handle the potential None case gracefully. src/eth/executor.rs [161] -let evm_result = parallel_executions.next().await.unwrap(); +let evm_result = match parallel_executions.next().await { + Some(result) => result, + None => return Err("No more executions available".into()), // Handle the error appropriately +};

---

✨ Improve tool usage guide:

---

Overview:
The improve tool scans the PR code changes, and automatically generates suggestions for improving the PR code. The tool can be triggered automatically every time a new PR is opened, or can be invoked manually by commenting on a PR.

• When commenting, to edit configurations related to the improve tool (pr_code_suggestions section), use the following template:

/improve --pr_code_suggestions.some_config1=... --pr_code_suggestions.some_config2=...

• With a configuration file, use the following template:

[pr_code_suggestions]
some_config1=...
some_config2=...

See the improve usage page for a comprehensive guide on using this tool.