feat: cosmetic proposal refactor block

[randygrok]

Overview

[github-actions]

The latest Buf updates on your PR. Results from workflow CI and Release / buf-check (pull_request).

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	⏩ skipped	✅ passed	✅ passed	Sep 15, 2025, 5:15 PM

[github-actions]

PR Preview Action v1.6.2
🚀 View preview at https://evstack.github.io/docs-preview/pr-2664/
Built to branch main at 2025-09-15 17:16 UTC. Preview will be ready when the GitHub Pages deployment is complete.

[gemini-code-assist]

Summary of Changes

Hello @randygrok, 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 introduces a comprehensive refactoring of the block package, transitioning from a single, large Manager component to a more modular and specialized architecture. This change aims to improve the maintainability, testability, and scalability of the block processing and synchronization logic by clearly separating responsibilities among new components like Executor, Syncer, Submitter, and Reaper, all orchestrated by a new block.Components interface. The node's integration with these new components has been updated accordingly, along with relevant documentation and tests.

Highlights

• Modular Architecture: The monolithic block.Manager has been decomposed into distinct, specialized components (Executor, Reaper, Submitter, Syncer, Cache Manager), improving code organization and maintainability.
• Centralized Component Management: A new block.Components struct centralizes the lifecycle management (start/stop) and configuration of these new block-related components, offering clear factory methods for different node roles (aggregator vs. sync).
• Enhanced DA Submission Logic: The Data Availability (DA) submission process has been refined with a dedicated DASubmitter component, incorporating more robust retry, backoff, and gas price management.
• Improved Syncing Mechanism: Block synchronization has been made more robust with dedicated DARetriever and P2PHandler components, all orchestrated by a new Syncer component.
• Internal Package Structure: Core block logic is now organized into internal packages (internal/cache, internal/common, internal/executing, internal/reaping, internal/submitting, internal/syncing), enforcing clearer separation of concerns and internal implementation details.

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 in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

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 issue 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.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

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. ↩

[claude]

Pull Request Review

Summary

This PR refactors the block production logic in the executor to improve code organization and readability. The changes break down the monolithic executionLoop into smaller, focused functions that follow the single responsibility principle.

✅ Positive Aspects

1. Improved Code Organization: Breaking down executionLoop into startBlockProduction, waitUntilProductionTime, blockProductionLoop, handleBlockTimer, and handleLazyTimer significantly improves readability and maintainability.

2. Better Separation of Concerns: Each function now has a clear, single responsibility:

   • waitUntilProductionTime: Handles initial delay logic
   • handleBlockTimer: Manages regular block production
   • handleLazyTimer: Handles lazy mode timer events

3. Enhanced Logging: Added more structured logging with additional context (e.g., wait_until, current_height, lazy_mode fields).

4. Cleaner State Management: The txsAvailable flag is now passed by reference to handler functions, making state mutations more explicit.

🔍 Code Quality Observations

1. Good Naming: Function names clearly describe their purpose (startBlockProduction vs the generic executionLoop).

2. Proper Resource Cleanup: Timer deferrals are maintained correctly in the refactored code.

3. Consistent Error Handling: Error handling patterns remain consistent with the original implementation.

⚠️ Potential Issues

1. Missing Documentation: While the code is more self-documenting through better naming, the new helper functions lack GoDoc comments. Consider adding documentation for exported or complex internal functions.

2. Testability: The refactoring makes the code more testable by breaking it into smaller units, but there don't appear to be new unit tests for the individual functions. Consider adding tests for:

   • waitUntilProductionTime with different scenarios (new chain vs existing chain)
   • handleBlockTimer with lazy mode on/off
   • handleLazyTimer behavior

🔒 Security Considerations

No security issues identified. The refactoring maintains the same security properties as the original code.

⚡ Performance Considerations

1. No Performance Regression: The refactoring doesn't introduce any additional allocations or computational overhead.

2. Slight Improvement: Passing txsAvailable by reference avoids potential confusion and is more idiomatic Go.

🧪 Test Coverage Recommendations

Given the existing test files (executor_test.go, executor_lazy_test.go), ensure that:

1. Existing tests still pass with the refactored code
2. Consider adding unit tests for the new helper functions to validate edge cases:
   • Genesis block timing
   • Lazy mode interactions
   • Context cancellation during wait periods

📝 Minor Suggestions

1. Consider adding a comment explaining why waitUntilProductionTime returns a boolean (to indicate whether to continue or context was cancelled).

2. The log message "new transactions available" could include the approximate count if easily accessible.

✅ Recommendation

APPROVE - This is a solid refactoring that improves code quality without changing functionality. The code is cleaner, more maintainable, and follows Go best practices. While adding tests for the new functions would be beneficial, the refactoring itself is well-executed and maintains backward compatibility.

The changes align well with the project's modular architecture principles as outlined in CLAUDE.md.

[gemini-code-assist]

Code Review

This pull request refactors the block production loop in executor.go by breaking down the large executionLoop function into several smaller, more focused functions. This significantly improves code readability and maintainability. The logic appears to be preserved. I've found one minor issue regarding a potential timer leak, for which I've left a specific comment with a suggested fix. Overall, this is a good cosmetic and structural improvement.

[gemini-code-assist]

Using time.After can lead to a resource leak. If the context is canceled (e.ctx.Done()), the timer created by time.After will not be garbage collected until it fires. This can be problematic if the delay is long.

It's better practice to use time.NewTimer and explicitly stop it to prevent this leak.

Suggested change

	if delay > 0 {
	e.logger.Info().Dur("delay", delay).Msg("waiting to start block production")
	e.logger.Info().
	Dur("delay", delay).
	Time("wait_until", waitUntil).
	Uint64("current_height", state.LastBlockHeight).
	Msg("waiting to start block production")
	select {
	case <-e.ctx.Done():
	return
	return false
	case <-time.After(delay):
	return true
	}
	}
	if delay > 0 {
	e.logger.Info().
	Dur("delay", delay).
	Time("wait_until", waitUntil).
	Uint64("current_height", state.LastBlockHeight).
	Msg("waiting to start block production")
	timer := time.NewTimer(delay)
	defer timer.Stop()
	select {
	case <-e.ctx.Done():
	return false
	case <-timer.C:
	return true
	}
	}

[julienrbrt]

I do not think the cognitive complexity is too high to value a split. Personally this makes it harder to read for me.
After discussion on Slack we agreed to close this.