Skip to content

Commit 4ba0035

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 dd5b7ee commit 4ba0035

File tree

1 file changed

+9
-13
lines changed

1 file changed

+9
-13
lines changed

crates/core/src/operations/connect.rs

Lines changed: 9 additions & 13 deletions
Original file line numberDiff line numberDiff line change
@@ -830,11 +830,9 @@ impl Operation for ConnectOp {
830830
};
831831
// Route through upstream (where the request came from) since we may
832832
// not have a direct connection to the target
833-
if let Some(upstream) = source_addr {
834-
network_bridge
835-
.send(upstream, NetMessage::V1(NetMessageV1::Connect(msg)))
836-
.await?;
837-
}
833+
network_bridge
834+
.send(upstream_addr, NetMessage::V1(NetMessageV1::Connect(msg)))
835+
.await?;
838836
}
839837

840838
if let Some(peer) = actions.expect_connection_from {
@@ -876,14 +874,12 @@ impl Operation for ConnectOp {
876874
};
877875
// Route the response through upstream (where the request came from)
878876
// since we may not have a direct connection to the joiner
879-
if let Some(upstream) = source_addr {
880-
network_bridge
881-
.send(
882-
upstream,
883-
NetMessage::V1(NetMessageV1::Connect(response_msg)),
884-
)
885-
.await?;
886-
}
877+
network_bridge
878+
.send(
879+
upstream_addr,
880+
NetMessage::V1(NetMessageV1::Connect(response_msg)),
881+
)
882+
.await?;
887883
return Ok(store_operation_state(&mut self));
888884
}
889885

0 commit comments

Comments
 (0)