Dial requests in `stream` behaviour are silently dropped

[kalabukdima]

Summary

I'm struggling to understand why the stream behavior calls try_send without handling the result here.
In our use case with hundreds of streams opened per second, it becomes a serious problem — some of the requested streams never trigger a dial, so nothing happens until a timeout on the caller's side.

Expected behavior

If a stream couldn't be opened, at least an error should be returned to the caller. Ideally, the behaviour should handle it itself and, e.g. queue the request for later, but I can see why it's problematic.

Actual behavior

Control::open_stream never returns, although some resources were allocated.

Relevant log output

2025-09-03T10:56:22.581481Z DEBUG sqd_network_transport::behaviour::stream_client: Opening stream to 12D3KooWFjzbi2MNkVpEDtdybAFuvixmTUzzijVNXxSo4cxAgpoR
2025-09-03T10:56:22.581514Z DEBUG libp2p_stream::control: Requesting new stream peer=12D3KooWFjzbi2MNkVpEDtdybAFuvixmTUzzijVNXxSo4cxAgpoR
2025-09-03T10:56:22.581546Z DEBUG libp2p_stream::shared: Not connected to peer, initiating dial peer=12D3KooWFjzbi2MNkVpEDtdybAFuvixmTUzzijVNXxSo4cxAgpoR

...Nothing mentioning "12D3KooWFjzbi2MNkVpEDtdybAFuvixmTUzzijVNXxSo4cxAgpoR" on TRACE level

2025-09-03T10:56:32.584019Z DEBUG sqd_network_transport::behaviour::stream_client: Connection to 12D3KooWFjzbi2MNkVpEDtdybAFuvixmTUzzijVNXxSo4cxAgpoR timed out

Possible Solution

A few options I see:

• Just use an unbounded channel. It might be the best option if the backpressure can't be correctly propagated.
• Await until the dial request is sent, propagating backpressure to the client to pause new requests until the behaviour is polled unblocking the channel.
• If none of the above is possible, at least return an error to the client, saying that there are too many concurrent dial attempts.

Version

0.55

Would you like to work on fixing this bug?

Yes