Sim: exercise unreliable delivery + reliability recovery over multi-hop - #169
Merged
Conversation
The fabric had a per-edge loss knob but every committed test ran at 0% loss, so the reliability layer (the whole reason it exists) was never exercised over the sim - a real gap. Close it. - MeshDappsNode takes an accelerated MeshCoreReliability.Options + resend poll, so a loss-recovery scenario runs in CI-time instead of on the 20 s production backoff. It also disables congestion-backoff: propagation is instantaneous in the sim, so the occupancy estimate is an artifact, and under heavy loss the extra resend traffic would otherwise inflate it and throttle recovery (a genuine production interaction, but a confound here). - MeshFabric gains a Dropped counter so a test can assert loss was genuinely exercised rather than lean on a flaky probabilistic control. - New test LossyMultiHop_ReliabilityRecoversEveryMessage_ExactlyOnce (0.3 and 0.4 per-hop loss over four hops): asserts every message is recovered, each delivered exactly once (idempotent under resend-after-lost-ACK), and Dropped > 0. Ran 5x with no flakiness; recovers in ~3-6 s. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KLbwvhE2cKCe8WPZNg8k17
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Closes a real gap flagged in review of the sim fabric: it had a per-edge loss knob but every test ran at 0% loss, so the reliability layer — the whole reason MeshCore needs one — was never exercised in the sim. This adds a lossy multi-hop reliability-recovery scenario.
How
MeshDappsNodenow takes an acceleratedMeshCoreReliability.Options+ resend-poll interval, so a loss-recovery test runs in CI-time (~3–6 s) instead of on the 20 s production backoff. It also setsCongestionBackoffFraction = 0: propagation is instantaneous in the sim so the occupancy estimate is an artifact, and under heavy loss the extra resend traffic would inflate it and throttle recovery. (That's a genuine production interaction — under heavy multi-hop loss, congestion backoff does slow reliability recovery — but it's a confound for isolating reliability here.)MeshFabricgains aDroppedcounter so the test asserts loss was genuinely exercised, rather than relying on a flaky probabilistic control.Test
LossyMultiHop_ReliabilityRecoversEveryMessage_ExactlyOnce— A ── R1 ── R2 ── R3 ── B over four hops at 30% and 40% per-edge loss:Dropped > 0(loss was real).Ran 5× with no flakiness; recovers in ~3–6 s.
🤖 Generated with Claude Code