chore: unify methods in eotsmanager #647
Conversation
There was a problem hiding this comment.
Pull Request Overview
This PR consolidates the EOTS manager's randomness generation methods by unifying the separate CreateRandomnessPairList and CreateRandomnessPairListWithInterval methods into a single function that accepts functional options to specify intervals.
- Unifies two separate randomness generation methods into one flexible API
- Introduces functional options pattern for optional interval configuration
- Removes duplicate gRPC service method and protobuf definitions
Reviewed Changes
Copilot reviewed 13 out of 13 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| eotsmanager/proto/eotsmanager.proto | Removes separate interval-based RPC method and adds optional interval field to existing request |
| eotsmanager/service/rpcserver.go | Consolidates RPC handlers and adds option processing logic |
| eotsmanager/eotsmanager.go | Introduces functional options pattern and unified interface |
| eotsmanager/localmanager.go | Merges two implementation methods into one with option handling |
| eotsmanager/client/rpcclient.go | Removes duplicate client method and unifies implementation |
| bsn/rollup/service/*.go | Updates callers to use new unified API with interval option |
| finality-provider/proto/*.pb.go | Updates protobuf version and adds gRPC method name constants |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
|
https://github.com/Mergifyio backport-to-release/v2.x |
|
https://github.com/Mergifyio backport release/v2.x |
| // interval is the optional height interval between consecutive randomness pairs | ||
| // If not set or 0, consecutive heights are used | ||
| optional uint64 interval = 5; |
There was a problem hiding this comment.
What do you think we have this as mandatory and require the client to use 1 explicitly for consecutive heights?
Right now interval == nil and interval == &1 have the same meaning, and type *uint64 is a bit weird in Go
There was a problem hiding this comment.
I think this comes to personal preference in "API" design, where I find it more intuitive not to have additional clutter in the method call
closes #648