iotaledger / iota / 32088388059

69%

Build Type

push

github

Committed by web-flow

Commit Message

fix(iota-core): tolerate out-of-order validator feedback timestamps (#12528)

# Description of change

`TimeDecayEwma::interval_alpha` asserted `debug_assert!(now >=
self.last_update, "Timestamps must be non-decreasing")`, but that is an
invariant the callers cannot provide, so the assert took down debug
builds under stress load.

There are two independent ways to reach it. First, feedback is stamped
with `Instant::now()` by its recorder — via
`OperationFeedback::ok_now`/`err_now` — *before* that recorder takes the
`client_stats` write lock in
`ValidatorClientMonitor::record_interaction_result`, so two recorders
reporting on the same validator can reach the stats in the opposite
order to their timestamps. `transaction_submitter`, `effects_certifier`
and `transaction_driver` all record concurrently, so this is ordinary
behaviour rather than an edge case.

Second, and needing no concurrency at all: `record_interaction_result`
scores the validator by calling `performance_score` with the incoming
feedback's timestamp, and that reads *every* operation's estimator. Each
operation advances on its own schedule — health checks fire on a timer
while submissions follow load — so a health check stamped behind a
submission reads the submit estimator at a timestamp older than its last
update.

The fix saturates the interval, which folds a late sample in with a
negligible weight instead of letting it rewrite the estimate, and stops
`last_update` moving backwards so a late sample cannot inflate the
intervals measured after it.

Two things worth a reviewer's attention. Release builds were never
affected by the crash, since `Instant::duration_since` saturates rather
than panicking, so this is a debug-only crash — but the `last_update`
change *is* a small behavioural change in release: previously a late
sample rewound the estimator's clock, which inflated the next interval
and so overweighted the next observation. Scoring is now stable against
out-of-order arrival. This... (continued)

Coverage Stats

5 of 5 new or added lines in 1 file covered. (100.0%)

749 existing lines in 44 files now uncovered.

169918 of 243691 relevant lines covered (69.73%)

464719.67 hits per line