Summary
In src/node/base_node.rs (BaseNode::search_by_id, lines ~83–140), the originator's search_by_id can block forever if the relayed node never responds.
Details
After relaying the request, the originator calls rx.recv() (line 121), which blocks indefinitely. If the downstream node crashes, drops the request, or the response is lost, the SyncSender is never used and recv() never returns. There is no timeout.
The nonce entry also stays in request_id_map forever in that scenario: the recv-error path (lines 130–138) only fires when the sender is dropped, not when a response is simply never sent.
Recommendation
- Replace the unbounded
rx.recv() with a bounded rx.recv_timeout(...).
- On timeout, remove the nonce entry from
request_id_map (same cleanup as the existing error path) and return an error.
Notes
Not introduced by #72 — pre-existing — but flagged during that PR's review as a good moment to address it.
Source: review comment on #72 (comment)
Summary
In
src/node/base_node.rs(BaseNode::search_by_id, lines ~83–140), the originator'ssearch_by_idcan block forever if the relayed node never responds.Details
After relaying the request, the originator calls
rx.recv()(line 121), which blocks indefinitely. If the downstream node crashes, drops the request, or the response is lost, theSyncSenderis never used andrecv()never returns. There is no timeout.The nonce entry also stays in
request_id_mapforever in that scenario: the recv-error path (lines 130–138) only fires when the sender is dropped, not when a response is simply never sent.Recommendation
rx.recv()with a boundedrx.recv_timeout(...).request_id_map(same cleanup as the existing error path) and return an error.Notes
Not introduced by #72 — pre-existing — but flagged during that PR's review as a good moment to address it.
Source: review comment on #72 (comment)