Skip to content

Commit 1c90c91

Browse files
sanityclaude
andcommitted
fix: route connect responses through upstream_addr
When accepting a connect request, route the response and observed address messages through the upstream peer (where the request came from) rather than trying to send directly to the joiner. The accepting peer may not have a direct connection to the joiner in relay scenarios. This mirrors how response forwarding already works at line 989-994. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <[email protected]>
1 parent eea52ed commit 1c90c91

File tree

1 file changed

+12
-5
lines changed

1 file changed

+12
-5
lines changed

crates/core/src/operations/connect.rs

Lines changed: 12 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -828,8 +828,10 @@ impl Operation for ConnectOp {
828828
target: target.clone(),
829829
address,
830830
};
831+
// Route through upstream (where the request came from) since we may
832+
// not have a direct connection to the target
831833
network_bridge
832-
.send(target.addr(), NetMessage::V1(NetMessageV1::Connect(msg)))
834+
.send(upstream_addr, NetMessage::V1(NetMessageV1::Connect(msg)))
833835
.await?;
834836
}
835837

@@ -870,10 +872,15 @@ impl Operation for ConnectOp {
870872
target: response_target,
871873
payload: response,
872874
};
873-
return Ok(store_operation_state_with_msg(
874-
&mut self,
875-
Some(response_msg),
876-
));
875+
// Route the response through upstream (where the request came from)
876+
// since we may not have a direct connection to the joiner
877+
network_bridge
878+
.send(
879+
upstream_addr,
880+
NetMessage::V1(NetMessageV1::Connect(response_msg)),
881+
)
882+
.await?;
883+
return Ok(store_operation_state(&mut self));
877884
}
878885

879886
Ok(store_operation_state(&mut self))

0 commit comments

Comments
 (0)