populate_run_ext_metrics_from_phases

Function populate_run_ext_metrics_from_phases 

Source
pub fn populate_run_ext_metrics_from_phases(
    phases: &[PhaseBucket],
    target: &mut BTreeMap<String, f64>,
)
Expand description

Sibling of populate_run_ext_metrics that mines per-phase metrics back into the run-level ext_metrics map. Closes the gap for registered metrics whose values live in PhaseBucket.metrics but never reach ext_metrics via the SampleSeries path (their read_sample returns None): avg_imbalance_ratio (sourced from MonitorSample windowing inside build_phase_buckets), iteration_rate (sourced from stimulus event totals inside build_phase_buckets_with_stimulus), and system_time_ns / user_time_ns (per-thread-group CPU-time deltas injected by phase_group_cpu_delta inside buckets_from_grouped). The fold is generic over every key present on any phase, so it carries any such phase-only metric (the ext-metrics-only set whose read_sample returns None). Keys with a typed GauntletRow field (TYPED_FIELD_NAMES) are SKIPPED: their run-level value comes from the typed accessor (which wins on read), so re-injecting them here would double-source the run aggregate — the hazard the const’s doc describes. Their per-phase PhaseBucket value still feeds per-phase rendering.

Per-phase reduction dispatch is described on PhaseBucket; the cross-phase fold here uses sample_count as the weight so Gauge(Avg) keys get the weighted mean (the correct cross-phase semantic for typical-load metrics) while other kinds fold per their natural reduction. Existing keys in target are not overwritten — read_sample path values win when both produced an entry.

Without this fill, cargo ktstr perf-delta silently misses these phase-only metrics (avg_imbalance_ratio, iteration_rate, system_time_ns, user_time_ns) in flat-row output because MetricDef::read falls back to ext_metrics and finds nothing.