tari-project / tari / 33536389238

76%

Build Type

push

github

Committed by web-flow

Commit Message

chore: remove duplicate peer dialing logic (#7984)

1. The reconciled status line could lie about what happened on its own
tick.
`dialer_state` was computed from a connection count snapshotted *before*
   `clean_connection_pool`, `disconnect_seed_peers`, reaping and
minimize-connections ran, any of which can drop connections, while the
gate
   below deliberately re-read the count. So the line could print
   `proactive dialer=idle` and then dial anyway a few statements later -
reproducing the exact "two numbers disagree on one tick" confusion this
line
was added to end. The count is now read once, after all the cleanup
passes,
and that single value feeds both the log line and the gate. The message
moves
with it and is reworded from "Performing" to "Performed", since every
number
   in it is now post-cleanup.

2. Pin the discriminator's dominant real-world shape.
`ConnectivityRequester::dial_peer` always sends `reply_tx: Some(..)`
whatever
`RefKind` it is handed, and both ordinary explicit dial paths -
messaging
(`protocol/messaging/outbound.rs`) and RPC (`protocol/rpc/context.rs`) -
ask
for `RefKind::Weak`. So `Weak` + `Some(reply_tx)` is the common explicit
dial,
not `Strong`, and no existing test covered it: a regression to testing
   `ref_kind` alone would have left all three passing while silently
circuit-breaking every RPC and messaging dial. Verified by making
exactly that
mutation - the three old tests still passed and only the new one failed.

3. Stop claiming single-chokepoint coverage that does not exist, and
remove the
duplicate predicate that made the claim tempting. `handle_dial_peer` is
the
   chokepoint for dials routed through the connectivity actor, but
`ProactiveDialer::dial_peers_concurrently` calls `try_send_dial_peer`
directly
and never passes through it, so the dialer's own candidate filter is
load
   bearing and cannot be removed. Rather than leave two independent
implementations, both now ask through
`ConnectivityConfig::is_circ... (continued)

Coverage Stats

175 of 194 new or added lines in 6 files covered. (90.21%)

1024 existing lines in 35 files now uncovered.

78614 of 124086 relevant lines covered (63.35%)

232651.64 hits per line