Conversation
`Control::accept` creates the channel behind `IncomingStreams` with a capacity of zero, and the connection handler hands each fully negotiated inbound stream over with `try_send` from within the swarm's poll. When a second stream for the same protocol arrives before the consumer has taken the previous one, it is dropped even though negotiation already succeeded: the remote sees a successful `open_stream` (and possibly a successful write) for data that is never delivered. This happens as soon as several peers open a stream for the same protocol at about the same time. `accept_with_buffer(protocol, n)` queues up to `n` negotiated streams. `accept` keeps its current behaviour (`accept_with_buffer(protocol, 0)`), so the change is non-breaking. Streams dropped because the buffer is full are now logged at `warn` instead of `debug`. Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
nikicat
force-pushed
the
stream-accept-with-buffer
branch
from
September 23, 2026 14:04
58c8cf8 to
9f259c8
Compare
nikicat
marked this pull request as ready for review
September 23, 2026 19:03
This branch has not been deployed
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
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.
Description
Control::acceptcreates the channel behindIncomingStreamswith a capacity of zero, and theconnection handler hands each fully negotiated inbound stream over with
try_sendfrom withinthe swarm's poll. If a second stream for the same protocol arrives before the consumer has taken
the previous one, it is dropped even though negotiation already succeeded: the remote sees a
successful
open_stream(and possibly a successful write) for data that is never delivered.This happens as soon as several peers open a stream for the same protocol at about the same time
(one-stream-per-message protocols hit it routinely).
This PR adds
Control::accept_with_buffer(protocol, n), which queues up tonnegotiated streams.acceptkeeps its current behaviour (it isaccept_with_buffer(protocol, 0)), so the change isnon-breaking and bumps
libp2p-streamto0.5.0-alpha.1. Streams dropped because the buffer isfull are now logged at
warninstead ofdebug, since the remote cannot tell they were lost.The new test opens 16 streams while nobody polls
IncomingStreamsand expects all 16 to bedelivered; it fails with a buffer of 0.
AI Assistance Disclosure
Tools used: Claude Code
Attestation:
Notes & open questions
acceptitself buffered with a default capacity, or to put thecapacity into a
Behaviourconfig. I keptacceptunchanged to avoid changing behaviour forexisting users; happy to switch if maintainers prefer one of those.
nis still dropped, because the handler cannot waitfor the consumer from within
poll. Thewarnlog makes that visible.Change checklist
🤖 Generated with Claude Code