Struct iapyx::WalletRequestGen

pub struct WalletRequestGen {
    rand: OsRng,
    multi_controller: MultiController,
    proposals: Vec<FullProposalInfo>,
    options: Vec<u8>,
    wallet_index: usize,
    update_account_before_vote: bool,
    vote_cast_counter: VoteCastCounter,
    block_date_generator: BlockDateGenerator,
    settings: Settings,
}

Vote request generator. Implements RequestGenerator interface which incorporates generator to load testing framework. Responsibility is to keep track of wallets under tests and prepare each time valid vote transaction whenever asked. There are two challenges:

• keeping track of spending counter and increase it each time fragment is sent. Current limitation is a lack of recovery scenario when transaction is failed (no resend strategy or spending counter revert)
• keeping track of valid proposals to vote. One can vote only once per proposal. Duplicated votes will result in failed transaction which can skew load test results. Therefore, we need to also know which proposals are eligible to vote on. Having in mind internal structure of vote plan (voteplan can have many proposals) and requirement to send batch of votes may result in different proposals from different voteplan.

Fields

rand: OsRng

multi_controller: MultiController

proposals: Vec<FullProposalInfo>

options: Vec<u8>

wallet_index: usize

update_account_before_vote: bool

vote_cast_counter: VoteCastCounter

block_date_generator: BlockDateGenerator

settings: Settings

Implementations

impl WalletRequestGen

pub fn new( multi_controller: MultiController, update_account_before_vote: bool, group: &str ) -> Result<Self, RequestGenError>

Creates new object

Errors

On connectivity with backend issues

pub fn random_vote(&mut self) -> Result<FragmentId, MultiControllerError>

Sends vote with random choice on behalf of random wallet. Having in mind account based model in Jormungandr blockchain we need to carefully select wallet which sends transaction. We should spread the use of wallets evenly to avoid inconsistency in spending-counter values. This struct does not control how fast votes should be send so we need to avoid situation that votes from account A will be send without prior confirmation of last vote sent from account A. Therefore a simple rolling index is use which traverse from left to right of collection. There is a silent assumption that collection is big enough to not cause mentioned problem with spending counter inconsistency.

Errors

Trait Implementations

impl RequestGenerator for WalletRequestGen

fn split(self) -> (Self, Option<Self>)

fn next(&mut self) -> Result<Request, RequestFailure>