chore: split rust lib #2445
chore: split rust lib #2445
Conversation
WalkthroughThis update refactors the Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant RollkitClientBuilder
participant RollkitClient
User->>RollkitClientBuilder: builder()
User->>RollkitClientBuilder: set endpoint/timeout/TLS
User->>RollkitClientBuilder: build() (async)
RollkitClientBuilder->>RollkitClient: create instance with config
RollkitClient-->>User: RollkitClient instance
User->>RollkitClient: get service client (Health, P2P, Store, Signer)
User->>ServiceClient: call method (concurrently, immutably)
Suggested reviewers
Poem
✨ Finishing Touches
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Summary of Changes
Hello @tac0turtle, 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 introduces a new Rust client library for interacting with Rollkit nodes via gRPC. It establishes a structured approach for client development by separating protobuf-generated types into a dedicated rollkit-types crate and providing a high-level gRPC client in the rollkit-client crate. The changes also include the necessary build infrastructure, CI integration, and documentation to support Rust development within the project.
Highlights
- New Rust Client Library: Introduced a comprehensive Rust client library for interacting with Rollkit nodes via gRPC, providing a robust and type-safe interface.
- Modular Crate Structure: The Rust client is organized into two distinct crates:
rollkit-typesfor protobuf-generated data structures androllkit-clientfor the high-level gRPC client logic, promoting modularity and reusability. - Advanced gRPC Client Features: The
rollkit-clientincludes enhanced features such as flexible connection management, configurable timeouts, and TLS support for secure communication with Rollkit nodes. - Automated Protobuf Code Generation: Implemented an automated process for generating Rust code from
.protofiles, including a custom build script that produces separate output for message types (without gRPC dependencies) and full gRPC services, controlled by feature flags. - CI/CD Integration: Integrated Rust build and protobuf generation steps into the project's CI/CD pipeline through a new GitHub Action and updated Makefile targets, ensuring consistent development and build environments.
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 is currently in preview and 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 to provide feedback.
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
-
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. ↩
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request introduces a comprehensive Rust client library for Rollkit, split into two crates: rollkit-types for protobuf-generated types and rollkit-client for the high-level gRPC client. The changes include the full library implementation, examples, tests, and CI/build system updates to support the new Rust code. The overall structure is well-thought-out, with a clear separation of concerns. My review focuses on improving maintainability, consistency, and idiomatic Rust practices in the new client library.
|
The latest Buf updates on your PR. Results from workflow CI and Release / buf-check (pull_request).
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (4)
client/crates/rollkit-types/build.rs (1)
35-37: Suggest consistent file existence handling.The file existence checks are good practice, but consider logging or handling the case where the generated file doesn't exist, as this could indicate a generation failure.
if generated_file.exists() { fs::rename(&generated_file, &messages_file)?; +} else { + eprintln!("Warning: Expected generated file {} not found", generated_file.display()); }Apply the same pattern to both rename operations for consistency.
Also applies to: 48-50
client/crates/rollkit-types/README.md (2)
33-33: Fix missing punctuation.Add a period at the end of the sentence for better readability.
-You're building for environments where gRPC is not needed +You're building for environments where gRPC is not needed.
65-65: Consider rephrasing to reduce repetition.The phrase "needing to regenerate" is used twice in nearby sentences. Consider varying the wording for better readability.
-Both files should be committed to ensure users can use the crate without needing to regenerate based on their feature selection. +Both files should be committed to ensure users can use the crate without requiring regeneration based on their feature selection.client/crates/rollkit-client/src/client.rs (1)
118-122: Consider enhancing the error message.The empty endpoint validation is good, but consider making the error message more descriptive to help users understand what's expected.
- return Err(RollkitClientError::InvalidEndpoint( - "Endpoint cannot be empty".to_string(), - )); + return Err(RollkitClientError::InvalidEndpoint( + "Endpoint cannot be empty. Please provide a valid URL (e.g., 'http://localhost:8080')".to_string(), + ));
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (14)
client/crates/rollkit-client/README.md(4 hunks)client/crates/rollkit-client/examples/basic.rs(4 hunks)client/crates/rollkit-client/src/client.rs(3 hunks)client/crates/rollkit-client/src/health.rs(1 hunks)client/crates/rollkit-client/src/lib.rs(3 hunks)client/crates/rollkit-client/src/p2p.rs(1 hunks)client/crates/rollkit-client/src/signer.rs(1 hunks)client/crates/rollkit-client/src/store.rs(1 hunks)client/crates/rollkit-types/Cargo.toml(2 hunks)client/crates/rollkit-types/README.md(2 hunks)client/crates/rollkit-types/build.rs(2 hunks)client/crates/rollkit-types/src/lib.rs(1 hunks)client/crates/rollkit-types/src/proto/rollkit.v1.messages.rs(1 hunks)client/crates/rollkit-types/tests/feature_test.rs(1 hunks)
🧰 Additional context used
🧠 Learnings (10)
📓 Common learnings
Learnt from: chatton
PR: rollkit/rollkit#2378
File: test/docker-e2e/base_test.go:22-32
Timestamp: 2025-06-18T12:52:25.919Z
Learning: In the rollkit codebase test/docker-e2e, the StartBridgeNode and StartRollkitNode methods in DockerTestSuite do not return errors. They handle error checking internally using s.Require().NoError(err) for their operations, so no external error handling is needed when calling these methods.
client/crates/rollkit-client/examples/basic.rs (3)
Learnt from: tzdybal
PR: rollkit/rollkit#1875
File: da/da_test.go:88-88
Timestamp: 2025-01-27T22:03:14.288Z
Learning: In the rollkit codebase, the `github.com/rollkit/go-da` package is imported with different aliases in test (`da`) and production code (`goDA`), but they refer to the same package. Suggestions to change between these aliases are unnecessary as they don't affect functionality.
Learnt from: chatton
PR: rollkit/rollkit#2378
File: test/docker-e2e/base_test.go:22-32
Timestamp: 2025-06-18T12:52:25.919Z
Learning: In the rollkit codebase test/docker-e2e, the StartBridgeNode and StartRollkitNode methods in DockerTestSuite do not return errors. They handle error checking internally using s.Require().NoError(err) for their operations, so no external error handling is needed when calling these methods.
Learnt from: chatton
PR: rollkit/rollkit#2378
File: test/docker-e2e/base_test.go:22-32
Timestamp: 2025-06-18T12:52:25.919Z
Learning: In the rollkit codebase test/docker-e2e, the StartBridgeNode and StartRollkitNode methods in DockerTestSuite do not return errors, so no error handling is needed when calling these methods.
client/crates/rollkit-types/src/lib.rs (3)
Learnt from: CR
PR: rollkit/rollkit#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T08:47:52.948Z
Learning: Applies to types/pb/**/*.proto : Protobuf definition files should be placed in the `types/pb/` directory.
Learnt from: tzdybal
PR: rollkit/rollkit#1875
File: da/da_test.go:178-178
Timestamp: 2025-01-27T22:02:44.446Z
Learning: In the test files of rollkit/rollkit repository, the `github.com/rollkit/go-da` package is imported with the alias `da`, while in production code it might use a different alias. The code should maintain consistent import aliases within each file.
Learnt from: tzdybal
PR: rollkit/rollkit#1875
File: da/da_test.go:88-88
Timestamp: 2025-01-27T22:03:14.288Z
Learning: In the rollkit codebase, the `github.com/rollkit/go-da` package is imported with different aliases in test (`da`) and production code (`goDA`), but they refer to the same package. Suggestions to change between these aliases are unnecessary as they don't affect functionality.
client/crates/rollkit-types/tests/feature_test.rs (4)
Learnt from: tzdybal
PR: rollkit/rollkit#1641
File: node/full_node_test.go:266-321
Timestamp: 2024-10-08T18:35:32.960Z
Learning: Issue #1663 was created to address adding comprehensive tests for error scenarios in `TestVoteExtension` in the rollkit repository.
Learnt from: tzdybal
PR: rollkit/rollkit#1641
File: node/full_node_test.go:266-321
Timestamp: 2024-06-10T19:23:16.839Z
Learning: Issue #1663 was created to address adding comprehensive tests for error scenarios in `TestVoteExtension` in the rollkit repository.
Learnt from: CR
PR: rollkit/rollkit#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T08:47:52.948Z
Learning: Update tests when changing functionality.
Learnt from: chatton
PR: rollkit/rollkit#2378
File: test/docker-e2e/base_test.go:22-32
Timestamp: 2025-06-18T12:52:25.919Z
Learning: In the rollkit codebase test/docker-e2e, the StartBridgeNode and StartRollkitNode methods in DockerTestSuite do not return errors. They handle error checking internally using s.Require().NoError(err) for their operations, so no external error handling is needed when calling these methods.
client/crates/rollkit-types/build.rs (1)
Learnt from: CR
PR: rollkit/rollkit#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T08:47:52.948Z
Learning: Applies to types/pb/**/*.proto : Protobuf definition files should be placed in the `types/pb/` directory.
client/crates/rollkit-client/src/lib.rs (1)
Learnt from: chatton
PR: rollkit/rollkit#2378
File: test/docker-e2e/base_test.go:22-32
Timestamp: 2025-06-18T12:52:25.919Z
Learning: In the rollkit codebase test/docker-e2e, the StartBridgeNode and StartRollkitNode methods in DockerTestSuite do not return errors. They handle error checking internally using s.Require().NoError(err) for their operations, so no external error handling is needed when calling these methods.
client/crates/rollkit-types/README.md (2)
Learnt from: CR
PR: rollkit/rollkit#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T08:47:52.948Z
Learning: Applies to types/pb/**/*.proto : Protobuf definition files should be placed in the `types/pb/` directory.
Learnt from: chatton
PR: rollkit/rollkit#2378
File: test/docker-e2e/base_test.go:22-32
Timestamp: 2025-06-18T12:52:25.919Z
Learning: In the rollkit codebase test/docker-e2e, the StartBridgeNode and StartRollkitNode methods in DockerTestSuite do not return errors. They handle error checking internally using s.Require().NoError(err) for their operations, so no external error handling is needed when calling these methods.
client/crates/rollkit-client/README.md (3)
Learnt from: Eoous
PR: rollkit/rollkit#2208
File: pkg/store/store.go:117-138
Timestamp: 2025-04-22T17:57:47.384Z
Learning: In the Rollkit pruning implementation, index entries (mapping block hash to height) are intentionally preserved even when block data is pruned to maintain a lightweight historical record of the blockchain structure.
Learnt from: chatton
PR: rollkit/rollkit#2378
File: test/docker-e2e/base_test.go:22-32
Timestamp: 2025-06-18T12:52:25.919Z
Learning: In the rollkit codebase test/docker-e2e, the StartBridgeNode and StartRollkitNode methods in DockerTestSuite do not return errors. They handle error checking internally using s.Require().NoError(err) for their operations, so no external error handling is needed when calling these methods.
Learnt from: chatton
PR: rollkit/rollkit#2378
File: test/docker-e2e/base_test.go:22-32
Timestamp: 2025-06-18T12:52:25.919Z
Learning: In the rollkit codebase test/docker-e2e, the StartBridgeNode and StartRollkitNode methods in DockerTestSuite do not return errors, so no error handling is needed when calling these methods.
client/crates/rollkit-types/src/proto/rollkit.v1.messages.rs (1)
Learnt from: CR
PR: rollkit/rollkit#0
File: CLAUDE.md:0-0
Timestamp: 2025-06-30T08:47:52.948Z
Learning: Applies to types/pb/**/*.proto : Protobuf definition files should be placed in the `types/pb/` directory.
client/crates/rollkit-client/src/store.rs (1)
Learnt from: Eoous
PR: rollkit/rollkit#2208
File: pkg/store/store.go:117-138
Timestamp: 2025-04-22T17:57:47.384Z
Learning: In the Rollkit pruning implementation, index entries (mapping block hash to height) are intentionally preserved even when block data is pruned to maintain a lightweight historical record of the blockchain structure.
🧬 Code Graph Analysis (4)
client/crates/rollkit-client/src/client.rs (5)
client/crates/rollkit-client/src/health.rs (1)
new(13-16)client/crates/rollkit-client/src/p2p.rs (1)
new(14-17)client/crates/rollkit-client/src/signer.rs (1)
new(14-17)client/crates/rollkit-client/src/store.rs (1)
new(15-18)client/crates/rollkit-types/src/proto/rollkit.v1.services.rs (8)
new(55-58)new(196-198)new(625-628)new(772-774)new(1044-1047)new(1157-1159)new(1397-1400)new(1578-1580)
client/crates/rollkit-types/build.rs (5)
client/crates/rollkit-client/src/health.rs (1)
new(13-16)client/crates/rollkit-client/src/p2p.rs (1)
new(14-17)client/crates/rollkit-client/src/signer.rs (1)
new(14-17)client/crates/rollkit-client/src/store.rs (1)
new(15-18)client/crates/rollkit-types/src/proto/rollkit.v1.services.rs (8)
new(55-58)new(196-198)new(625-628)new(772-774)new(1044-1047)new(1157-1159)new(1397-1400)new(1578-1580)
client/crates/rollkit-client/src/health.rs (1)
client/crates/rollkit-types/src/proto/rollkit.v1.services.rs (10)
livez(1103-1127)livez(1138-1144)new(55-58)new(196-198)new(625-628)new(772-774)new(1044-1047)new(1157-1159)new(1397-1400)new(1578-1580)
client/crates/rollkit-types/src/proto/rollkit.v1.messages.rs (3)
types/state.go (1)
State(20-39)core/sequencer/sequencing.go (1)
Batch(33-35)client/crates/rollkit-types/src/proto/rollkit.v1.services.rs (2)
as_str_name(997-1004)from_str_name(1006-1014)
🪛 LanguageTool
client/crates/rollkit-types/README.md
[uncategorized] ~33-~33: A period might be missing here.
Context: ...ding for environments where gRPC is not needed ## How It Works This crate generates ...
(AI_EN_LECTOR_MISSING_PUNCTUATION_PERIOD)
[style] ~65-~65: You have already used this phrasing in nearby sentences. Consider replacing it to add variety to your writing.
Context: ... ensure users can use the crate without needing to regenerate based on their feature selec...
(REP_NEED_TO_VB)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (7)
- GitHub Check: test / Build All Rollkit Binaries
- GitHub Check: test / Build Rollkit Docker Image
- GitHub Check: test / Build Rollkit EVM Single Docker Image
- GitHub Check: test / Run Unit Tests
- GitHub Check: Analyze (rust)
- GitHub Check: Analyze (go)
- GitHub Check: Summary
🔇 Additional comments (21)
client/crates/rollkit-client/examples/basic.rs (2)
1-1: LGTM! API simplification aligns with thread-safe design.The removal of
SignerClientfrom the imports simplifies the example and aligns with the crate's API changes.
19-19: Excellent: Immutable bindings reflect the thread-safe API changes.The change from mutable to immutable bindings for
health,p2p, andstorecorrectly demonstrates the new thread-safe API where client methods take&selfinstead of&mut self.Also applies to: 30-30, 52-52
client/crates/rollkit-types/src/lib.rs (1)
2-8: Excellent feature flag implementation for modular compilation.The conditional compilation correctly includes different proto files based on the
grpcfeature flag:
- Without
grpc: includes only message types (no tonic dependencies)- With
grpc: includes full gRPC servicesThis provides the desired modularity for users who only need message types for serialization.
client/crates/rollkit-types/tests/feature_test.rs (2)
1-7: Good coverage of message type availability.The test correctly verifies that core message types (
Block,Header,State) are always available regardless of feature flags, ensuring the message-only compilation works as expected.
9-23: Excellent conditional testing of gRPC types.The test properly verifies that gRPC client types are only available when the
grpcfeature is enabled. Usingstd::any::type_nameis an appropriate approach to verify type existence without instantiation.client/crates/rollkit-types/Cargo.toml (2)
14-17: Well-structured feature flag configuration.The feature dependencies are logically organized:
default = ["grpc"]maintains backward compatibilitygrpc = ["tonic", "transport"]enables full gRPC functionalitytransport = ["tonic/transport"]enables tonic's transport featureThis provides the desired modularity while maintaining a sensible default.
27-27: Correct optional tonic dependency.Making tonic optional and conditional on the transport feature enables the modular compilation approach while keeping the transport feature enabled by default.
client/crates/rollkit-types/build.rs (2)
19-22: Good practice: Explicit output directory creation.Creating the output directory explicitly before generation ensures the build succeeds even if the directory doesn't exist.
26-37: Correct dual generation strategy.The approach of generating both message-only and full service proto files is sound, allowing users to avoid regeneration based on feature flags.
client/crates/rollkit-client/src/lib.rs (2)
23-71: Excellent documentation enhancement for the builder pattern!The new documentation sections effectively demonstrate the builder pattern usage with clear examples for custom timeouts and TLS configuration. The examples are well-structured and provide good guidance for users.
81-92: Good API convenience improvements.The re-exports of
RollkitClientBuilderandClientTlsConfigmake the API more convenient for users by reducing the need for multiple imports.client/crates/rollkit-client/src/health.rs (1)
19-38: Excellent thread-safety improvement!The change from mutable to immutable receivers with client cloning makes these methods thread-safe and enables concurrent usage. The pattern is consistently applied across all methods.
Note that cloning the inner client for each call introduces some performance overhead, but this is typically acceptable for gRPC clients since they're lightweight wrappers around channels.
client/crates/rollkit-types/README.md (1)
5-42: Comprehensive documentation for the new feature system!The Features, Usage, and How It Works sections provide excellent guidance for users. The explanation of the dual file generation approach (
messages.rsvsservices.rs) is particularly valuable.client/crates/rollkit-client/README.md (3)
51-87: Excellent addition of builder pattern and TLS documentation!The new sections provide clear examples of the builder pattern usage and TLS configuration options. The examples are well-structured and demonstrate both basic and advanced use cases effectively.
109-131: Good update to reflect thread-safety and API changes.The clarification that all service methods are now thread-safe and the updated Store Service API method names accurately reflect the code changes.
141-171: Excellent concurrent usage example!This example effectively demonstrates the thread-safe nature of the service clients and provides a practical pattern for concurrent operations. The use of
clone()and spawned tasks clearly shows how to leverage the new immutable method signatures.client/crates/rollkit-client/src/p2p.rs (1)
20-55: Consistent thread-safety implementation!The same excellent pattern from
HealthClientis applied here - changing to immutable receivers with client cloning. This maintains consistency across all service clients and enables concurrent usage of P2P operations.client/crates/rollkit-client/src/signer.rs (1)
20-22: Excellent thread-safety improvements!The change from
&mut selfto&selfwith inner client cloning is a great improvement that enables concurrent usage of theSignerClient. Thetonic::transport::Channelis designed to be cheaply cloneable, making this approach both thread-safe and performant.Also applies to: 28-30, 36-38, 44-46
client/crates/rollkit-client/src/client.rs (1)
11-18: Well-implemented builder pattern!The
RollkitClientBuilderprovides excellent flexibility for client configuration while maintaining clean, readable code. The implementation includes proper validation, reasonable defaults, and comprehensive error handling.Also applies to: 85-157
client/crates/rollkit-client/src/store.rs (1)
21-25: Consistent thread-safety improvements and better API design!The changes follow the same thread-safety pattern as other client implementations, and the method names are more descriptive (e.g.,
get_block_by_heightvsget_block). This provides a cleaner, more intuitive API while maintaining thread-safety.Also applies to: 31-35, 41-43, 49-51, 57-61, 67-71, 77-79, 85-87
client/crates/rollkit-types/src/proto/rollkit.v1.messages.rs (1)
1-340: Comprehensive protobuf message definitions!This generated file provides a well-structured set of message definitions covering all essential blockchain operations including signing, blocks, state management, networking, and health status. The
HealthStatusenum with proper string conversion methods is particularly well-implemented.The separation of message-only definitions from gRPC services (as mentioned in the AI summary) is a good architectural decision that enables flexible usage patterns.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #2445 +/- ##
==========================================
- Coverage 72.77% 72.74% -0.04%
==========================================
Files 67 67
Lines 6403 6403
==========================================
- Hits 4660 4658 -2
- Misses 1346 1347 +1
- Partials 397 398 +1
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
| @@ -1,3 +1,9 @@ | |||
| pub mod v1 { | |||
Overview
Summary by CodeRabbit
New Features
Improvements
Bug Fixes
Documentation