Is your feature request related to a problem? Please describe.
When transactions are sent, the metrics collected by print_progress_report only reflect what's eventually confirmed on chain and saved to the DB. This gives the averaging algorithm a skewed input, which makes the metrics inaccurate, especially in short-duration spam runs.
Describe the solution you'd like
We need a new way of getting txs_sent -- it's currently defined as confirmed_txs + failed_txs which is derived from the DB (run_txs).
We need to internally track the number of txs sent as we send them, and pass a thread-safe (read-only) reference to that number to print_progress_report.
Additional context
see contender_core::util::print_progress_report
Is your feature request related to a problem? Please describe.
When transactions are sent, the metrics collected by
print_progress_reportonly reflect what's eventually confirmed on chain and saved to the DB. This gives the averaging algorithm a skewed input, which makes the metrics inaccurate, especially in short-duration spam runs.Describe the solution you'd like
We need a new way of getting
txs_sent-- it's currently defined asconfirmed_txs + failed_txswhich is derived from the DB (run_txs).We need to internally track the number of txs sent as we send them, and pass a thread-safe (read-only) reference to that number to
print_progress_report.Additional context
see
contender_core::util::print_progress_report