Final multi-target summaries were printed by iterating the BTreeMap<String, StatsCollector> directly, which sorted headings lexicographically by label instead of following CLI argument order.
The final summary loop in run_stream (crates/irtt-cli/src/cmd/client/run.rs) now iterates setup.targets (the canonical prepared CLI order) and looks up each target's stats from the map with .expect(...), since every prepared target is guaranteed to have a collector inserted before the run begins. The BTreeMap itself, and all .entry() lookups used during event processing, are unchanged.
Regression
Previously, irtt-cli z=host-z a=host-a m=host-m printed final summaries in the order a, m, z (BTreeMap iteration order) instead of z, a, m (CLI argument order). Added multi_target_final_summary_preserves_cli_argument_order in crates/irtt-cli/tests/client_multi_target.rs, which runs three real targets labeled z, a, m against InTreeServer fakes and asserts the target: <label> summary headings appear in that CLI order. Verified this test fails on the pre-fix code and passes after the fix.
Scope
No changes to event ordering, managed scheduling, statistics collection, event-time lookup (.entry() calls), target-label semantics, CSV/TSV/JSONL behavior, or single-target summary formatting.
COR-04 (panic=abort terminal restoration) is explicitly out of scope and was not touched.
No dependency additions, crate version bumps, or CHANGELOG updates.
## Summary
- Final multi-target summaries were printed by iterating the `BTreeMap<String, StatsCollector>` directly, which sorted headings lexicographically by label instead of following CLI argument order.
- The final summary loop in `run_stream` (`crates/irtt-cli/src/cmd/client/run.rs`) now iterates `setup.targets` (the canonical prepared CLI order) and looks up each target's stats from the map with `.expect(...)`, since every prepared target is guaranteed to have a collector inserted before the run begins. The `BTreeMap` itself, and all `.entry()` lookups used during event processing, are unchanged.
## Regression
Previously, `irtt-cli z=host-z a=host-a m=host-m` printed final summaries in the order a, m, z (BTreeMap iteration order) instead of z, a, m (CLI argument order). Added `multi_target_final_summary_preserves_cli_argument_order` in `crates/irtt-cli/tests/client_multi_target.rs`, which runs three real targets labeled z, a, m against `InTreeServer` fakes and asserts the `target: <label>` summary headings appear in that CLI order. Verified this test fails on the pre-fix code and passes after the fix.
## Scope
- No changes to event ordering, managed scheduling, statistics collection, event-time lookup (`.entry()` calls), target-label semantics, CSV/TSV/JSONL behavior, or single-target summary formatting.
- COR-04 (panic=abort terminal restoration) is explicitly out of scope and was not touched.
- No dependency additions, crate version bumps, or CHANGELOG updates.
## Verification
- `cargo fmt --all -- --check`
- `cargo check --workspace --all-targets --all-features --locked`
- `cargo test --workspace --all-targets --all-features --locked` (all passed, including the new regression test)
- `cargo clippy --workspace --all-targets --all-features --locked -- -D warnings`
- `RUSTDOCFLAGS="-D warnings" cargo doc --workspace --all-features --no-deps --locked`
- `cargo check -p irtt-cli --no-default-features --all-targets --locked`
- `git diff --check`
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Summary
BTreeMap<String, StatsCollector>directly, which sorted headings lexicographically by label instead of following CLI argument order.run_stream(crates/irtt-cli/src/cmd/client/run.rs) now iteratessetup.targets(the canonical prepared CLI order) and looks up each target's stats from the map with.expect(...), since every prepared target is guaranteed to have a collector inserted before the run begins. TheBTreeMapitself, and all.entry()lookups used during event processing, are unchanged.Regression
Previously,
irtt-cli z=host-z a=host-a m=host-mprinted final summaries in the order a, m, z (BTreeMap iteration order) instead of z, a, m (CLI argument order). Addedmulti_target_final_summary_preserves_cli_argument_orderincrates/irtt-cli/tests/client_multi_target.rs, which runs three real targets labeled z, a, m againstInTreeServerfakes and asserts thetarget: <label>summary headings appear in that CLI order. Verified this test fails on the pre-fix code and passes after the fix.Scope
.entry()calls), target-label semantics, CSV/TSV/JSONL behavior, or single-target summary formatting.Verification
cargo fmt --all -- --checkcargo check --workspace --all-targets --all-features --lockedcargo test --workspace --all-targets --all-features --locked(all passed, including the new regression test)cargo clippy --workspace --all-targets --all-features --locked -- -D warningsRUSTDOCFLAGS="-D warnings" cargo doc --workspace --all-features --no-deps --lockedcargo check -p irtt-cli --no-default-features --all-targets --lockedgit diff --check