runner: default UntilCoverageStable can never converge for a simulation with no coverage assertions
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 76/100
Research direction
Start in crates/moonpool-sim/src/runner/builder.rs at lines 1329 and 1518, then compare the existing coverage behavior with test_simulation_builder_basic and coverage_plateau.rs. Add a test for a simulation with zero coverage assertions and verify that the default UntilCoverageStable run stops without convergence_timeout while emitting the proposed warning.
Written by the indexing model from the issue text.
Description
Found during the pre-release source audit of 8d9e779 (read-only, nothing compiled or run). Severity: high (first-impression trap). Status: confirmed.
Where
crates/moonpool-sim/src/runner/builder.rs:1329(let all_reached = all_sometimes_count > 0 && ...)crates/moonpool-sim/src/runner/builder.rs:1518(scan_assertion_slots)
What
all_reached requires all_sometimes_count > 0. scan_assertion_slots only counts slots that were actually evaluated, and every assert_reachable! inside moonpool sits on a fault path (fault_injector.rs, orchestrator.rs, process_manager.rs, the engines), never on the happy path.
Failure scenario
A new user writes a workload with no assert_sometimes! or assert_reachable!, keeps the default UntilCoverageStable { plateau_seeds: 10, max_iterations: 1000 }, and gets 1000 seeds followed by convergence_timeout: true. The repository's own tests never exercise this (test_simulation_builder_basic pins set_iterations(3); coverage_plateau.rs always registers coverage assertions).
Proposed fix
Treat all_sometimes_count == 0 as vacuously reached so the plateau alone can stop the run, and emit one warning that no coverage assertion was observed. Add a test with zero coverage assertions.
- Dominant language
- Rust
- Stars
- 49
- Forks
- 3
- Avg merge
- 1h 4m
- Merged PRs (30d)
- 41
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from PierreZ/moonpool
-
bug simulation
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
bug github_actions
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
-
bug simulation
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
-
bug simulation
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
-
documentation release-blocker
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
All issues in PierreZ/moonpool
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#610 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
gitbutlerapp/gitbutler#15998 · 1 comment ·
-
bug triage:deciding
Difficulty 1/5 Under an hour Newbie friendliness 88/100
open-telemetry/otel-arrow#4132 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100