Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Comments

test: faster block time#3094

Open
alpe wants to merge 3 commits intomain from
alex/bench1
Open

test: faster block time #3094
alpe wants to merge 3 commits intomain from
alex/bench1

Conversation

@alpe
Copy link
Contributor

@alpe alpe commented Feb 20, 2026
edited by coderabbitai bot
Loading

Overview

Run benchmark with 5ms block time

Summary by CodeRabbit

  • Tests
    • Optimized EVM contract benchmark testing with improved polling mechanism and block time configuration for enhanced test reliability.

Copy link
Contributor

github-actions bot commented Feb 20, 2026
edited
Loading

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

BuildFormatLintBreakingUpdated (UTC)
✅ passed⏩ skipped✅ passed✅ passedFeb 24, 2026, 7:32 AM

Copy link
Contributor

Summary of Changes

Hello @alpe, I'm Gemini Code Assist1 ! 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 focuses on enhancing the performance of EVM contract benchmarks. By reducing the EVM node's block time and refining the transaction receipt polling mechanism, the changes aim to achieve faster and more efficient test runs, thereby improving the overall development and testing workflow.

Highlights

  • Benchmark Optimization: Optimized EVM node block time in benchmarks to 10ms, significantly speeding up test execution.
  • Transaction Receipt Polling: Improved transaction receipt waiting logic by inlining require.Eventually with a faster 10ms polling interval, reducing variance and avoiding RPC overload.
  • Code Cleanup: Cleaned up test code by removing the now-unused waitForReceipt helper function and its associated ethclient import.

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

Changelog
  • test/e2e/evm_contract_bench_test.go
    • Removed unused ethclient import.
    • Configured the EVM node to use a 10ms block time for benchmarks.
    • Replaced the waitForReceipt helper function call with an inline require.Eventually block for transaction inclusion, using a faster polling interval.
    • Deleted the waitForReceipt helper function.
Activity
  • No specific human activity (comments, reviews, or progress updates) has been recorded for this pull request yet.
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.

Copy link
Contributor

claude bot commented Feb 20, 2026
edited
Loading

Claude finished @alpe's task in 1m 29s —— View job


Code Review

  • Gather context and read changed files
  • Analyze changes and provide review feedback

The PR spans two commits:

  • d7823ae — removes waitForReceipt helper, adds 10ms block time, inlines polling at 10ms
  • 20cc9d0 — extracts const blockTime = 5 * time.Millisecond, ties polling interval to blockTime/2

Overall: A clean, focused improvement. The changes reduce benchmark variance and remove dead code. A few minor points worth noting:


PR Description Mismatch

The PR description says "Test with 10ms block time" but the actual committed code sets blockTime = 5 * time.Millisecond. The description is stale from the first commit. Worth updating to reflect the final value.


Polling Interval

blockTime/2 = 2.5ms is aggressive polling. The previous waitForReceipt polled at 50ms; the first commit dropped that to 10ms, and the second commit brought it to 2.5ms. For a local benchmark against a single node this is fine, but the comment "avoiding RPC overload" is somewhat ironic at 2.5ms intervals. The logic of polling at half the block time makes sense for minimizing measurement latency — just worth being aware of the load implications if block time is ever configured shorter.


Gemini's Constant Suggestion — Already Addressed

The inline review comment from Gemini suggesting a constant is already implemented in 20cc9d0. No action needed.


waitForReceipt Removal

The old helper returned *types.Receipt which wasn't used at the call site in the benchmark. Inlining is appropriate here. The signature removal also cleans up the unused ethclient import correctly.


Minor: require.Eventually timeout vs block time ratio

With a 5ms block time and a 2-second timeout, the caller gets ~400 block intervals before failure. This is a generous headroom for CI environments where timing can be unpredictable, which is reasonable.


Summary: The changes are correct and improve benchmark quality. Only actionable item is updating the PR description to say 5ms instead of 10ms.

Copy link
Contributor

@gemini-code-assist gemini-code-assist bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Code Review

This pull request speeds up the BenchmarkEvmContractRoundtrip test by reducing the block time to 10ms and adjusting the transaction receipt polling interval accordingly. The changes are effective and include removing a now-unused helper function. I've added one suggestion to improve maintainability by using a constant for the new block time and polling interval.

"--evnode.instrumentation.tracing_endpoint", collector.endpoint(),
"--evnode.instrumentation.tracing_sample_rate", "1.0",
"--evnode.instrumentation.tracing_service_name", "ev-node-bench",
"--evnode.node.block_time=10ms",
Copy link
Contributor

@gemini-code-assist gemini-code-assist bot Feb 20, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

medium

The hardcoded value 10ms is also used for the polling interval on line 109. To improve maintainability and prevent these values from diverging in the future, consider defining a constant for it.

For example, you could add const fastBlockTime = 10 * time.Millisecond at the start of the function and use it here ("--evnode.node.block_time=" + fastBlockTime.String()) and for the polling interval (fastBlockTime).

Copy link

codecov bot commented Feb 20, 2026
edited
Loading

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 60.95%. Comparing base (a5ef771) to head (c6f17f3).

Additional details and impacted files
@@ Coverage Diff @@
## main #3094 +/- ##
==========================================
- Coverage 60.97% 60.95% -0.03% 
==========================================
 Files 113 113 
 Lines 11617 11617 
==========================================
- Hits 7084 7081 -3 
- Misses 3734 3737 +3 
 Partials 799 799 
Flag Coverage Δ
combined 60.95% <ø> (-0.03%) ⬇️

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.

Copy link
Contributor

coderabbitai bot commented Feb 24, 2026
edited
Loading

📝 Walkthrough

Walkthrough

This change refactors a benchmark test by replacing a custom waitForReceipt polling function with inline polling using require.Eventually. A block time constant is introduced and passed as a runtime argument to configure the ev-node, while the ethclient import is removed.

Changes

Cohort / File(s) Summary
Test Refactoring
test/e2e/evm_contract_bench_test.go
Removed unused ethclient import, introduced blockTime constant (5ms), added --evnode.node.block_time runtime argument, replaced waitForReceipt helper with inline require.Eventually polling (2s timeout, blockTime/2 interval), eliminated waitForReceipt function.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

🐰 A helper once waited with care,
For receipts floating through the air,
But now with require.Eventually bright,
The polling runs sleek and tight!
Block time ticks, five milliseconds gleam, ⏱️✨

🚥 Pre-merge checks | ✅ 3
✅ Passed checks (3 passed)
Check name Status Explanation
Title check ✅ Passed The title 'test: faster block time' directly describes the main change—configuring benchmarks to use a faster (5ms) block time instead of the default.
Description check ✅ Passed The description addresses the Overview section with 'Run benchmark with 5ms block time' but lacks context, rationale, or linked issues as suggested by the template.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
  • 📝 Generate docstrings (stacked PR)
  • 📝 Generate docstrings (commit on current branch)
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
  • Commit unit tests in branch alex/bench1

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands and usage tips.

@alpe alpe marked this pull request as ready for review February 24, 2026 08:02
@alpe alpe requested a review from chatton February 24, 2026 08:03
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@test/e2e/evm_contract_bench_test.go`:
- Line 46: The comment notes a mismatch between the PR description ("10ms") and
the test constant blockTime; update either the PR description or the constant in
evm_contract_bench_test.go so they match—specifically change the constant named
blockTime from 5 * time.Millisecond to 10 * time.Millisecond if the test is
intended to run at 10ms, or revise the PR text to state 5ms if that is intended;
ensure the symbol blockTime is the one you modify so the code and description
remain consistent.

i️ Review info

Configuration used: defaults

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between a5ef771 and c6f17f3.

📒 Files selected for processing (1)
  • test/e2e/evm_contract_bench_test.go

func BenchmarkEvmContractRoundtrip(b *testing.B) {
workDir := b.TempDir()
sequencerHome := filepath.Join(workDir, "evm-bench-sequencer")
const blockTime = 5 * time.Millisecond
Copy link
Contributor

@coderabbitai coderabbitai bot Feb 24, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

⚠️ Potential issue | 🟡 Minor

PR description says "10ms" but blockTime is set to 5ms.

The PR description states "Test with 10ms block time," but the constant is 5 * time.Millisecond. Please align the description (or the constant) to avoid confusion.

🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/e2e/evm_contract_bench_test.go` at line 46, The comment notes a mismatch
between the PR description ("10ms") and the test constant blockTime; update
either the PR description or the constant in evm_contract_bench_test.go so they
match—specifically change the constant named blockTime from 5 * time.Millisecond
to 10 * time.Millisecond if the test is intended to run at 10ms, or revise the
PR text to state 5ms if that is intended; ensure the symbol blockTime is the one
you modify so the code and description remain consistent.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@coderabbitai coderabbitai[bot] coderabbitai[bot] left review comments

@julienrbrt julienrbrt julienrbrt approved these changes

@chatton chatton Awaiting requested review from chatton

+1 more reviewer

@gemini-code-assist gemini-code-assist[bot] gemini-code-assist[bot] left review comments

Reviewers whose approvals may not affect merge requirements

Assignees

@alpe alpe

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

AltStyle によって変換されたページ (->オリジナル) /