Summary

When multiple peers simultaneously request the same block from a provider, only 1–2 requests receive responses. The remaining requests are silently ignored, causing those peers to timeout despite having active connections and receiving confirmation that the provider has the block.

Environment

• rust-ipfs (this repository)
• Tokio async runtime
• libp2p networking
• Bitswap
• 6-node local Docker network

Network Setup

• 6-node Docker mesh network (full connectivity, 30 total connections)
• All nodes connected before the test begins
• Node 1: content publisher / provider
• Nodes 2–6: subscribers / requesters
• Gossipsub used for PubSub message propagation

Reproduction Steps

1. All 6 nodes subscribe to a PubSub topic
2. Node 1 publishes content and broadcasts the CID via PubSub
3. Nodes 2–6 receive the PubSub message within ~100ms of each other
4. All 5 nodes simultaneously request the block from Node 1 (identified via message.source)
5. Only 1–2 nodes receive the block successfully
6. Remaining 3–4 nodes timeout waiting for a response

Observed Behavior

All 5 requesting nodes follow the same initial flow:

DEBUG sent want block session=bafir... peer_id=12D3KooW...
DEBUG have block session=bafir... peer_id=12D3KooW...   ← provider confirms it has the block
DEBUG change state to next_block session=bafir...
INFO  sending block request to next peer session=bafir... next_peer_id=12D3KooW...

However, only 1–2 nodes continue with:

INFO  storing block peer_id=12D3KooW... cid=bafir...
INFO  block stored in block store session=bafir... block=bafir...
INFO  obtaining block completed. session=bafir...

The remaining 3–4 nodes never receive any response after sending the block request.

Detailed Log Comparison

Node 4 (succeeded):

{"timestamp":"2026-01-12T15:59:25.667212264Z","level":"INFO","message":"sending block request to next peer","session":"bafireihtrmj4avivcjd6xs3o3o5chiy7k5rw5waip72jejerwjfhlslm74","next_peer_id":"12D3KooWNwauZpWVDfAMT5rFCKRXdjndUATE6hzA133zNMJRyNHf"}
{"timestamp":"2026-01-12T15:59:25.667914026Z","level":"INFO","message":"storing block","peer_id":"12D3KooWNwauZpWVDfAMT5rFCKRXdjndUATE6hzA133zNMJRyNHf","cid":"bafireihtrmj4avivcjd6xs3o3o5chiy7k5rw5waip72jejerwjfhlslm74"}

Node 2 (failed):

{"timestamp":"2026-01-12T15:59:25.667344107Z","level":"INFO","message":"sending block request to next peer","session":"bafireihtrmj4avivcjd6xs3o3o5chiy7k5rw5waip72jejerwjfhlslm74","next_peer_id":"12D3KooWNwauZpWVDfAMT5rFCKRXdjndUATE6hzA133zNMJRyNHf"}

No further logs — the request is never fulfilled.

Both requests were sent within ~130µs of each other to the same provider for the same CID.

Expected Behavior

If a provider has a block, it should respond to all incoming requests for that CID.
When 5 peers request the same block concurrently, all 5 should receive responses.

Workarounds Attempted

• Retry logic (5 retries, 10s timeout each)
  → No improvement; provider consistently ignores the same peers on subsequent attempts
• Verified active connections between all peers before and during requests
• Verified block availability (all peers receive have block confirmation)

Hypothesis

On the provider side, Bitswap session handling may be:

• Processing only the first incoming request and dropping concurrent duplicates
• Not correctly handling multiple concurrent WANT_BLOCK messages for the same CID
• Hitting an internal state, lock, or session constraint that prevents multiple responses