Skip to main content

Module replay

Module replay 

Source
Expand description

ReplayDriver: feeds a previously captured golden-master trace back through the Driver trait, tick by tick, instead of a live OPC DA connection or the in-process FOPDT simulator.

core-replay-harness (crates/bhtune-core/tests/golden_replay.rs) already proves the pure MrftEngine reproduces the legacy C# application’s behavior exactly, by feeding a fixture’s recorded ticks directly into engine.step(Tick { time, pv }). That test cannot exercise anything in this crate at all – bhtune-core cannot depend on bhtune-driver, which depends on it – so it says nothing about whether the real async Driver abstraction a live run actually goes through (tag-based indirection, TagValue/ TagWrite conversions, Quality, Send-across-.await dispatch behind Box<dyn Driver>/Arc<dyn Driver>) introduces its own bugs on top of a provably-correct engine. ReplayDriver closes that gap: it serves the exact same recorded trace through the genuine trait boundary, so a validation test can drive a real MrftEngine through it and confirm the same golden trace still reaches the same answer – see this module’s own mrft_engine_replays_the_golden_trace_through_the_real_driver_trait test.

Structs§

RecordedWrite
A single MV write ReplayDriver observed, in the order Driver::write was called – what a validation test inspects afterward (via ReplayDriver::writes) to see exactly what an engine driven through the real Driver trait chose to write, without needing its own separate bookkeeping alongside the driver’s.
ReplayDriver
Serves a captured (time, PV) trace through the real Driver trait, for validating that a live MrftEngine run reproduces a golden-master trace’s result when driven through the actual async abstraction – not just when fed the trace directly, as core-replay-harness already does at the pure-engine level.
ReplaySample
One recorded (time, PV) sample from a captured trace – the two fields ReplayDriver actually needs to serve a PV read.
ReplayTraceExhausted
The error Driver::read wraps in DriverError::Operation when the configured PV tag is read after every recorded sample has already been consumed.