fix(gossip): stop a mesh of strangers from crowding out the real subscriber - #20
Merged
Merged
Conversation
…criber
ensureTopicMeshMinimum measured a topic's mesh with MeshPeers, which counts
peers grafted on spec that have never claimed the channel. Two consequences,
both of which keep the one peer that matters out of the mesh:
- the DLo check returns early, so no grafting happens at all; and
- the slot count is D - len(meshPeers), which is 0 once six strangers are
in, so even reaching selectMeshCandidates could not pick anyone.
Publishing only reaches peers known to subscribe — a subscription is learned
from a GRAFT and nothing else — so a counterpart that is connected and on the
channel still never receives a publish. Both ends then publish into the
substrate and neither hears the other, while every counter reads healthy.
Both quantities now come from ConfirmedMeshPeers, matching the fix already
applied to maybeDiscoverTopicPeers; this was the same bug in the second of the
two places that consult the mesh.
The test asserts a mesh of six unconfirmed peers does not stop the one
confirmed subscriber from being grafted. It fails on main.
Note on scope: this is a real defect and the test pins it, but it was not what
unblocked the observed DM failure — a control-frame dedup in mosh was. Ships
on its own merits, not as the fix for that symptom.
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.
ensureTopicMeshMinimummeasured a topic's mesh withMeshPeers, which counts peers grafted on spec that have never claimed the channel. That broke grafting two ways at once:DLocheck returns early, so no grafting happens; andD - len(meshPeers), which is 0 once six strangers are in — so even reachingselectMeshCandidatescould not select anyone.Why it matters: publishing only reaches peers known to subscribe, and a subscription is learned from a GRAFT and nothing else. A counterpart that is connected and genuinely on the channel therefore never receives a publish. Both ends publish into the substrate, neither hears the other, and every counter reads healthy the whole time.
Both quantities now come from
ConfirmedMeshPeers— the same correction already applied tomaybeDiscoverTopicPeersin #18. This was the identical bug in the second of the two places that consult the mesh; fixing only the first left the door shut.Test
A mesh of six unconfirmed peers must not stop the one confirmed subscriber from being grafted. Fails on
main— and note it fails there even with the DLo check corrected alone, which is how the slot-count half surfaced.Scope, honestly
This is a real defect and the test pins it, but it is not what unblocked the DM failure I was chasing. That turned out to be a control-frame dedup in mosh dropping every handshake retransmission. This ships on its own merits.
mesh, gossip and transport suites pass; build and vet clean.