refactor(validator): refactor gRPC server implementation#1959
refactor(validator): refactor gRPC server implementation#1959
Conversation
This commit refactors the gRPC server implementation in the validator crate. The API implementation is now split into separate modules for each endpoint.
kkovaacs
force-pushed
the
krisztian/refactor-validator-grpc-server
branch
from
aa3a80b to
3da29dc
Compare
There was a problem hiding this comment.
Pull request overview
Refactors the validator gRPC API implementation to the new per-method trait-based framework and splits each RPC method into its own module, aligning with the approach described in #1885.
Changes:
- Migrated validator RPC method implementations to generated per-method traits (
Status,SubmitProvenTransaction,SignBlock). - Split each validator RPC method into its own file under
crates/validator/src/server/. - Added a changelog entry documenting the validator gRPC server refactor.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.
Show a summary per file
| File | Description |
|---|---|
| crates/validator/src/server/mod.rs | Removes the direct api_server::Api impl and wires the server to rely on the new generated blanket implementation; adds per-method modules. |
| crates/validator/src/server/status.rs | Implements the per-method Status trait for ValidatorServer. |
| crates/validator/src/server/submit_proven_transaction.rs | Implements the per-method SubmitProvenTransaction trait, including decode/handle/encode split. |
| crates/validator/src/server/sign_block.rs | Implements the per-method SignBlock trait, including decode/handle/encode split and semaphore serialization. |
| CHANGELOG.md | Documents the validator gRPC API refactor. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
| async fn handle(&self, _input: Self::Input) -> tonic::Result<Self::Output> { | ||
| unimplemented!() | ||
| } | ||
|
|
||
| fn decode(_request: ()) -> tonic::Result<Self::Input> { | ||
| unimplemented!() | ||
| } | ||
|
|
||
| fn encode(_output: Self::Output) -> tonic::Result<grpc::validator::ValidatorStatus> { | ||
| unimplemented!() | ||
| } |
There was a problem hiding this comment.
handle, decode, and encode are left as unimplemented!(), which will panic if these trait methods are ever used (e.g., if the generated blanket impl stops calling the overridden full, or if tests/helpers call handle directly). It would be safer to implement the intended decode/handle/encode flow and rely on the default full implementation (and adjust Input/Output types accordingly) rather than overriding full and leaving required methods unimplemented.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Mirko-von-Leipzig
left a comment
Mirko-von-Leipzig
left a comment
There was a problem hiding this comment.
I didn't inspect the code too much with the assumption that its largely a copy-paste from the original.
| fn encode(output: Self::Output) -> tonic::Result<grpc::blockchain::BlockSignature> { | ||
| Ok(grpc::blockchain::BlockSignature { signature: output.to_bytes() }) | ||
| } |
There was a problem hiding this comment.
I suspect all of our encode calls are infallible.. Should we change the API to replace Result<T> with T? Maybe in the future we may need fallible encoding? Can't imagine why though..
| Ok(grpc::validator::ValidatorStatus { | ||
| version: env!("CARGO_PKG_VERSION").to_string(), | ||
| status: "OK".to_string(), | ||
| chain_tip: self.chain_tip.load(Ordering::Relaxed), | ||
| validated_transactions_count: self.validated_transactions_count.load(Ordering::Relaxed), | ||
| signed_blocks_count: self.signed_blocks_count.load(Ordering::Relaxed), | ||
| }) |
There was a problem hiding this comment.
We just need to be careful when we're adding instrumentation at the top level, that this doesn't override anything important.
As outlined in #1885, after having the build-time generation of related traits and blanket implementations (PR #1950) we can start moving our GRPC API implementations to the new framework.
This PR does this for the validator GRPC API. As suggested in the issue, each method is moved to its own file.
Closes #1970