Refactor ClientOption to solana-client crate#7735
Refactor ClientOption to solana-client crate#7735lijunwangs merged 2 commits intoanza-xyz:masterfrom
Conversation
| /// connections efficiently. | ||
| /// * [`TpuClientNextClient`]: Relies on the `tpu-client-next` crate and | ||
| /// requires a reference to a [`Keypair`]. | ||
| pub enum ClientOption<'a> { |
There was a problem hiding this comment.
I wanted to say that it can be used also in forwarding_stage.rs. But the ForwardingClientOption now supports multihoming so it is not the same now. to double check, @alexpyattaev am i right that multihoming is irrelevant for rpc and also for the votes over quic?
There was a problem hiding this comment.
Yes. I will see if we can integrate that for forward in the future PRs.
There was a problem hiding this comment.
refactoring and sharing ForwardingClientOption is problematic because of NodeMultihoming is declared in gossip. We need a new home for this code in order for it to be used in solana-client.
KirillLykov
left a comment
There was a problem hiding this comment.
looks like a good idea to move it there
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## master #7735 +/- ##
=========================================
- Coverage 83.0% 83.0% -0.1%
=========================================
Files 812 812
Lines 357192 357192
=========================================
- Hits 296771 296766 -5
- Misses 60421 60426 +5 🚀 New features to boost your workflow:
|
* Refactor ClientOption to solana-client crate * cargo.toml style
* Refactor ClientOption to solana-client crate * cargo.toml style
Problem
ClientOption can be used for multiple use cases, leaving it in RPC is a misnomer.
Summary of Changes
Moving ClientOption to the more opportune Solana-client crate
Fixes #