8c40e0da48
Multiple code paths could each fire an outgoing connect to the same peer simultaneously with no coordination: the existing connections.contains_key() check under a lock, drop lock, connect pattern leaves a window where another path passes its own check and spawns a parallel attempt. Auto-reconnect, rebalance-slots, and the relay-introduction target-side handler were the three identified races (rank 1–3 in the pre-release audit). Observable as multiple near-simultaneous "Auto-connected to peer [hex]" / "Target-side hole punch succeeded to [hex]" log lines for the same peer. Fix: add `pending_connects: Arc<std::sync::Mutex<HashSet<NodeId>>>` to ConnectionManager plus a `PendingConnectGuard` RAII type. Entry to each outgoing-connect path now acquires a guard via `try_begin_connect(peer)` under the CM lock; the guard inserts the NodeId into the set and the Drop impl removes it. Concurrent callers for the same peer see the NodeId already in `pending_connects` (or already in the `connections` / `sessions` maps) and return None, so they skip their attempt. Scope: - Only gates outgoing duplicates to the SAME peer. Different peers connect independently. Inbound connections from the guarded peer are not affected — the simultaneous-open race is still resolved by the existing check-before-insert on registration. - The std::sync::Mutex is held for a single O(1) hash op on acquire / drop — never across an await — so the guard lifetime spans the full connect attempt without blocking anything else. Sites wired: - Auto-reconnect after unexpected disconnect (connection.rs ~4492) - Rebalance-slots outgoing loop (connection.rs ~8049) - Relay-introduction target-side both handlers (connection.rs ~3945, ~5783) Tests: `pending_connect_guard_gates_same_peer_and_releases_on_drop` asserts second same-peer acquire is refused, different peers acquire independently, and drop releases the slot. 121 / 121 core tests pass. |
||
|---|---|---|
| .. | ||
| cli | ||
| core | ||
| tauri-app | ||