Skip to content

Conversation

@julienrbrt
Copy link
Member

Overview

@github-actions
Copy link
Contributor

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

BuildFormatLintBreakingUpdated (UTC)
✅ passed⏩ skipped✅ passed✅ passedFeb 10, 2026, 1:39 PM

@gemini-code-assist
Copy link
Contributor

Summary of Changes

Hello @julienrbrt, 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 prepares the project for the v1.0.0-rc.4 release candidate. It involves updating module dependencies across various applications to reflect the new release version and commenting out local replace directives in go.mod files, which are typically used during development to point to local paths.

Highlights

  • Version Updates: Updated the core ev-node module to v1.0.0-rc.4 across all affected applications.
  • Dependency Management: Commented out local replace directives in go.mod files for apps/evm, apps/grpc, and apps/testapp, indicating a shift from local development paths to published module versions.
  • EVM Module Update: Specifically updated the ev-node/execution/evm module to v1.0.0-rc.3 in apps/evm.
  • Changelog Entry: Added a new section for v1.0.0-rc.4 in the CHANGELOG.md.

🧠 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
  • CHANGELOG.md
    • Added a new version heading for v1.0.0-rc.4.
  • apps/evm/go.mod
    • Updated github.com/evstack/ev-node to v1.0.0-rc.4.
    • Updated github.com/evstack/ev-node/execution/evm to v1.0.0-rc.3.
    • Commented out local replace directives.
  • apps/evm/go.sum
    • Updated module checksums for ev-node and evm dependencies.
  • apps/grpc/go.mod
    • Updated github.com/evstack/ev-node to v1.0.0-rc.4.
    • Commented out local replace directives.
  • apps/grpc/go.sum
    • Updated module checksums for ev-node and grpc dependencies.
  • apps/testapp/go.mod
    • Updated github.com/evstack/ev-node to v1.0.0-rc.4.
    • Commented out a local replace directive.
  • apps/testapp/go.sum
    • Updated module checksums for the ev-node dependency.
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
Copy link
Contributor

claude bot commented Feb 10, 2026

Claude finished @julienrbrt's task in 1m 36s —— View job


Code Review Complete

I've conducted a comprehensive review of this release candidate preparation PR. Below is my detailed analysis across multiple dimensions.


Summary

This PR prepares the codebase for the v1.0.0-rc.4 release by:

  • Updating version references from rc.3 to rc.4 across application modules
  • Commenting out local replace directives to use published module versions
  • Adding a CHANGELOG entry for rc.4

1. Code Quality & Dependency Management

Strengths

  • Consistent Version Updates: The version bumps are properly synchronized across all three app modules (evm, grpc, testapp)
  • Proper go.sum Updates: All go.sum files have been correctly updated with checksums for the new versions
  • CHANGELOG Entry: Following Keep a Changelog format with proper PR reference

⚠️ Issues & Concerns

CRITICAL: Version Inconsistency Detected

The execution layer modules were not updated and still reference v1.0.0-rc.3:

  1. execution/evm/go.mod:7 - Still points to github.com/evstack/ev-node v1.0.0-rc.3
  2. execution/grpc/go.mod:8 - Still points to github.com/evstack/ev-node v1.0.0-rc.3

This creates a version mismatch where:

  • App modules depend on ev-node v1.0.0-rc.4
  • Execution modules depend on ev-node v1.0.0-rc.3
  • App modules then transitively depend on execution modules

This inconsistency can cause:

  • Build issues when the apps are used as standalone modules
  • Confusion about which version is actually being used
  • Potential runtime behavior differences if rc.3 and rc.4 have breaking changes

Fix version inconsistency →


2. Release Preparation Best Practices

⚠️ CHANGELOG Completeness

The CHANGELOG entry for v1.0.0-rc.4 only includes one change:

## v1.0.0-rc.4

### Changes

- Skip draining when exec client unavailable. [#3060](https://github.com/evstack/ev-node/pull/3060)

Question: Are there other changes between rc.3 and rc.4 that should be documented? Looking at recent commits, I see:

If these are part of rc.4, they should be included in the CHANGELOG.

⚠️ Replace Directive Management

Commenting out replace directives is correct for release builds, but consider:

  1. Team Workflow Impact: Developers will need to uncomment these for local development. Consider documenting this in CONTRIBUTING.md or CLAUDE.md
  2. Automation Opportunity: This manual process is error-prone. Consider:
    • A Makefile target like make release-prep that handles this automatically
    • Pre-release CI checks to verify replace directives are commented out
    • A script to toggle between development and release mode

3. Testing & Reliability

Missing Test Validation

For a release candidate, I would expect to see evidence that:

  1. Integration tests pass with the new versions
  2. E2E tests pass to ensure apps work correctly with published modules
  3. Build verification that apps can be built without local replace directives

Recommendation: Before merging, run:

make test-integration
make test-e2e
make build-all

Especially verify that builds work without the replace directives, as this is the configuration external users will experience.


4. Documentation & Developer Experience

⚠️ Version Management Documentation

The project would benefit from:

  1. Release Checklist: Document the steps for preparing RC releases
  2. Version Dependency Matrix: Clearly document which versions are compatible
  3. Local Development Setup: Explain when to use replace directives vs published versions

5. Security & Configuration

No Security Concerns

This is a purely mechanical version bump with no code changes, so no security implications.


6. Architecture & Modularity

💡 Observation: Module Dependency Strategy

The project uses a complex multi-module structure with:

  • Core module at v1.0.0-rc.1 (stable across releases)
  • Main ev-node module at v1.0.0-rc.X (incrementing)
  • Execution modules at varying versions (evm at rc.3, grpc at rc.1)
  • App modules tracking main ev-node version

Consider: Document the versioning strategy:

  • When does core get a version bump?
  • When do execution/* modules get bumped?
  • What's the relationship between these versions?

Action Items

Must Fix Before Merge

  1. ✅ Update execution/evm/go.mod to reference ev-node v1.0.0-rc.4
  2. ✅ Update execution/grpc/go.mod to reference ev-node v1.0.0-rc.4
  3. ✅ Run go mod tidy in both execution directories
  4. ✅ Update go.sum files accordingly
  5. ✅ Verify all tests pass with published module versions

Should Consider

  1. Review CHANGELOG for completeness (include build(deps): Bump the all-go group across 4 directories with 5 updates #3058, chore(execution/evm): fix logs #3056 if applicable)
  2. Add release preparation automation to prevent manual errors
  3. Document version management strategy in CLAUDE.md
  4. Run full test suite before merging

Nice to Have

  1. Create a release checklist document
  2. Add CI check to verify replace directives are commented in release branches
  3. Document the development workflow for toggling replace directives

Overall Assessment

This is a standard release preparation PR, but it has a critical version inconsistency in the execution layer modules that must be fixed before merging. The mechanical changes are correct, but the execution modules were missed during the version update sweep.

Once the version inconsistency is resolved and tests are verified, this will be ready to merge.

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 primarily focuses on updating module versions to v1.0.0-rc.4 across various go.mod and go.sum files, and adding a corresponding entry to the CHANGELOG.md. The replace directives in the go.mod files have been commented out, which is a common step when preparing for a release. Overall, the changes are consistent with a release candidate preparation.

Comment on lines +5 to +8
//replace (
// github.com/evstack/ev-node => ../../
// github.com/evstack/ev-node/execution/evm => ../../execution/evm
//)
Copy link
Contributor

Choose a reason for hiding this comment

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

medium

The replace directives have been commented out. While this is standard for release preparation (assuming the modules are now published), it might affect local development workflows for contributors who rely on these local replacements. Please ensure that the local development setup or documentation is updated to reflect this change, or consider adding a note about how to handle local development if these directives are needed.

Comment on lines +5 to +8
//replace (
// github.com/evstack/ev-node => ../../
// github.com/evstack/ev-node/execution/grpc => ../../execution/grpc
//)
Copy link
Contributor

Choose a reason for hiding this comment

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

medium

The replace directives have been commented out. While this is standard for release preparation (assuming the modules are now published), it might affect local development workflows for contributors who rely on these local replacements. Please ensure that the local development setup or documentation is updated to reflect this change, or consider adding a note about how to handle local development if these directives are needed.

go 1.25.6

replace github.com/evstack/ev-node => ../../
//replace github.com/evstack/ev-node => ../../
Copy link
Contributor

Choose a reason for hiding this comment

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

medium

The replace directive has been commented out. While this is standard for release preparation (assuming the module is now published), it might affect local development workflows for contributors who rely on this local replacement. Please ensure that the local development setup or documentation is updated to reflect this change, or consider adding a note about how to handle local development if this directive is needed.

@codecov
Copy link

codecov bot commented Feb 10, 2026

Codecov Report

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

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #3062      +/-   ##
==========================================
+ Coverage   61.85%   61.87%   +0.01%     
==========================================
  Files         111      111              
  Lines       11123    11123              
==========================================
+ Hits         6880     6882       +2     
+ Misses       3505     3502       -3     
- Partials      738      739       +1     
Flag Coverage Δ
combined 61.87% <ø> (+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 julienrbrt enabled auto-merge February 10, 2026 14:00
@julienrbrt julienrbrt added this pull request to the merge queue Feb 10, 2026
@tac0turtle tac0turtle removed this pull request from the merge queue due to a manual request Feb 10, 2026
@tac0turtle tac0turtle merged commit e83b64c into main Feb 10, 2026
47 of 52 checks passed
@tac0turtle tac0turtle deleted the julien/prep-rc4 branch February 10, 2026 14:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants