Struct ValidatorClientMonitor

pub struct ValidatorClientMonitor<A: Clone> { /* private fields */ }

Monitors validator interactions from the client’s perspective.

This component:

• Collects client-side metrics from TransactionDriver operations
• Runs periodic health checks on all validators from the client
• Maintains client-observed statistics for reliability and latency
• Provides intelligent validator selection based on client-observed performance
• Handles epoch changes by cleaning up stale validator data

The monitor runs a background task for health checks and uses moving averages to smooth client-side measurements.

Implementations

impl<A> ValidatorClientMonitor<A>

where A: AuthorityAPI + Send + Sync + 'static + Clone,

pub fn new( config: ValidatorClientMonitorConfig, metrics: Arc<ValidatorClientMetrics>, authority_aggregator: Arc<ArcSwap<AuthorityAggregator<A>>>, ) -> Arc<Self>

impl<A: Clone> ValidatorClientMonitor<A>

pub fn record_interaction_result(&self, feedback: OperationFeedback)

Record client-observed interaction result with a validator.

Records operation results including success/failure status and latency from the client’s perspective. Updates both Prometheus metrics and internal client statistics. This is the primary interface for the TransactionDriver to report client-observed validator interactions. TODO: Consider adding a byzantine flag to the feedback.

pub fn select_shuffled_preferred_validators( &self, committee: &Committee, tx_type: TxType, delta: f64, ) -> Vec<AuthorityName>

Select validators based on client-observed performance for the given transaction type.

The current committee is passed in to ensure this function has the latest committee information.

Also the tx type is passed in so that we can select validators based on their respective latencies for the transaction type.

Validators with latencies within delta of the lowest latency in the given transaction type are shuffled, to balance the load among the fastest validators.

Returns a vector containing all validators, where

1. Fast validators within delta of the lowest latency are shuffled.
2. Remaining slow validators are sorted by latency in ascending order.