feat: make reaper poll duration configurable

[chatton]

Overview

Enable reaper poll interval to be configurable to help reduce E2E tx latency

[github-actions]

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

Build	Format	Lint	Breaking	Updated (UTC)
✅ passed	⏩ skipped	✅ passed	✅ passed	Jan 5, 2026, 3:15 PM

[gemini-code-assist]

Summary of Changes

Hello @chatton, 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 enhances the system's configurability by allowing users to set the interval for the "reaper" component's polling of the execution layer. This change provides greater control over transaction detection latency and the associated RPC load, enabling operators to optimize performance based on their specific needs.

Highlights

• Configurable Reaper Poll Interval: The pull request introduces a new configuration option to control the interval at which the "reaper" component polls the execution layer for new transactions.
• Reduced Transaction Latency: By making the reaper poll duration configurable, users can now fine-tune this setting to potentially reduce end-to-end transaction latency.
• New Configuration Flag: A new command-line flag, node.scrape_interval, has been added to allow users to specify the desired poll duration.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

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.

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]

Claude finished @chatton's task in 1m 54s —— View job

---

Comprehensive Code Review

I've completed a thorough review of this PR. Overall, this is a well-implemented feature that makes the reaper polling interval configurable. The code quality is good, and the changes are clean and focused. Below are my detailed findings:

---

Summary

Purpose: Enable configuration of the reaper poll interval to reduce E2E transaction latency.

Changes:

• Added new ScrapeInterval configuration option to NodeConfig
• Removed now-unused DefaultInterval constant from reaping package
• Added *.out to .gitignore (addresses reviewer request)
• Updated tests to include the new configuration parameter

---

Code Quality & Architecture ✅

Strengths:

• Clean separation of concerns - configuration defined in config package, used in block package
• Follows existing patterns for adding configuration flags (consistent with BlockTime, LazyBlockInterval, etc.)
• The DurationWrapper type is used correctly for YAML/time.Duration parsing
• Removal of the DefaultInterval constant eliminates dead code (addresses reviewer feedback)
• The change is minimal and focused - doesn't introduce architectural complexity

Observations:

• The implementation correctly passes config.Node.ScrapeInterval.Duration to reaping.NewReaper() (block/components.go:230)
• Validation in reaping.NewReaper() ensures the interval cannot be zero, preventing misconfiguration

---

Configuration Management ✅

Strengths:

• Comprehensive documentation in the struct tag comment explaining purpose, trade-offs, and providing examples
• Default value of 1 second is reasonable and maintains existing behavior
• Configuration can be set via CLI flag, YAML file, or environment variable (standard pattern)
• The flag is properly registered in AddFlags() and tested in TestAddFlags()

Documentation Quality:

ScrapeInterval DurationWrapper `mapstructure:"scrape_interval" yaml:"scrape_interval" 
comment:"Interval at which the reaper polls the execution layer for new transactions. 
Lower values reduce transaction detection latency but increase RPC load. 
Examples: \"250ms\", \"500ms\", \"1s\"."`

This is excellent - it clearly explains:

• What the parameter controls
• The trade-off (latency vs RPC load)
• Concrete examples

---

Testing Coverage ⚠️ Needs Improvement

What's Good:

• Test flag count updated correctly (44 → 45)
• Flag assertion added in TestAddFlags() to verify the new flag exists with correct default
• Test helper updated to set ScrapeInterval in test configurations

What's Missing (addresses reviewer comment):
The reviewer (gemini-code-assist) correctly identified that while you added the flag assertion on line 66 of config_test.go:

assertFlagValue(t, flags, FlagScrapeInterval, DefaultConfig().Node.ScrapeInterval)

This only verifies the default value. There's no test that verifies:

1. The flag can be set via command line and properly overrides defaults
2. The flag can be set via YAML configuration
3. The configured value is actually used by the reaper

Recommendation:
Consider adding a test case to TestLoad() that sets FlagScrapeInterval via flag arguments and verifies it's properly loaded, similar to how FlagBlockTime is tested:

"--rollkit.node.scrape_interval", "2s",

Then assert:

assert.Equal(t, 2*time.Second, config.Node.ScrapeInterval.Duration, "ScrapeInterval should be set from flag")

---

Error Handling & Resilience ✅

Strengths:

• Validation in reaping.NewReaper() prevents zero interval:

  if scrapeInterval == 0 {
      return nil, errors.New("scrape interval cannot be empty")
  }

• Error wrapping follows Go best practices
• The reaper already has exponential backoff for failures, independent of the scrape interval

No Issues Found - Error handling is appropriate for this change.

---

Security Considerations ✅

Analysis:

• No security implications identified
• Configuration parameter doesn't expose sensitive data
• No injection or validation bypass risks
• Lower scrape intervals increase RPC load but that's an operational concern, not a security issue

---

Performance & Resource Efficiency ✅

Trade-offs Properly Documented:
The configuration comment correctly identifies the performance trade-off:

• Lower values: Reduce transaction detection latency (better for E2E testing)
• Higher values: Reduce RPC load on the execution layer

Implementation Correctness:

• The interval is used in reaperLoop() via time.NewTicker(r.interval) (reaper.go:92)
• The ticker is properly reset during backoff scenarios (reaper.go:118, 124)
• No resource leaks introduced

Recommendation:
For production use, operators should monitor RPC load and adjust based on their needs. The 1-second default is reasonable.

---

Documentation ✅

Strengths:

• Flag description is clear: "interval at which the reaper polls the execution layer for new transactions"
• YAML comment provides excellent guidance with examples
• PR description clearly states the motivation: "reduce E2E tx latency"

No Additional Documentation Needed - The inline documentation is sufficient.

---

Code Consistency & Style ✅

Strengths:

• Follows existing patterns exactly (compare with BlockTime, LazyBlockInterval)
• Flag naming convention matches: FlagScrapeInterval with prefix FlagPrefixEvnode + "node.scrape_interval"
• YAML field naming follows snake_case convention: scrape_interval
• Go naming follows camelCase: ScrapeInterval

No Style Issues Found

---

Review of Existing Reviewer Feedback

gemini-code-assist's feedback:

1. ✅ Remove unused DefaultInterval constant - ADDRESSED in commit 203c668
2. ⚠️ Add test coverage for the new flag - PARTIALLY ADDRESSED (see Testing section above)

julienrbrt's feedback:

1. ✅ Add *.out to .gitignore - ADDRESSED in commit bb341eb

---

Final Recommendations

Must Address:

None - The implementation is functionally correct and safe to merge.

Should Consider:

1. Testing: Add an integration test or extend TestLoad() to verify the flag can be set via command line and properly overrides YAML/defaults. This would provide stronger confidence that the configuration flows end-to-end.

2. Optional - Validation: Consider adding validation to ensure ScrapeInterval is reasonable (e.g., >= 100ms). While not strictly necessary, it could prevent operator mistakes. However, this may be over-engineering for this use case.

Nice to Have:

1. Add a log message in reaper.Start() that includes the configured interval for operational visibility (already done! Line 87 of reaper.go logs the interval).

---

Conclusion

This is a clean, well-implemented feature that follows established patterns in the codebase. The code quality is high, documentation is excellent, and the changes are focused and minimal.

Approval Status: ✅ Recommended for merge after considering the testing feedback above.

The existing test coverage provides basic validation, and the implementation is safe. The suggestion for additional integration testing is a quality improvement rather than a blocking issue.

---

Great work! The implementation demonstrates good understanding of the codebase architecture and Go best practices.

[gemini-code-assist]

Code Review

This pull request introduces a new configuration option, scrape_interval, to control the reaper's polling duration. This is a valuable addition for tuning node performance, especially for reducing end-to-end transaction latency. The implementation looks good, adding the necessary flag, configuration property, and default value. I've included a couple of suggestions for improvement: one regarding test coverage for the new flag and another for code cleanup by removing a now-unused constant.

[gemini-code-assist]

Now that the reaper interval is configurable and passed in here, the reaping.DefaultInterval constant appears to be unused. It would be good to remove it from block/internal/reaping/reaper.go to avoid dead code.

[julienrbrt]

+1 on this, cc @chatton

[gemini-code-assist]

It's great that you've added this new configuration flag. To ensure it's working as expected and to maintain test coverage, please consider adding a test case for FlagScrapeInterval in TestAddFlags within pkg/config/config_test.go. You'll also likely need to update the expectedFlagCount in that test to ensure all flags are accounted for.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 58.74%. Comparing base (66b491b) to head (c57b2af).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #2951   +/-   ##
=======================================
  Coverage   58.73%   58.74%           
=======================================
  Files          90       90           
  Lines        8720     8722    +2     
=======================================
+ Hits         5122     5124    +2     
  Misses       3011     3011           
  Partials      587      587           

Flag	Coverage Δ
combined	58.74% <100.00%> (+<0.01%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[julienrbrt]

Can you add *.out in gitignore?