refactor(tor): replace legacy Tor integration - #2583
Conversation
|
Claude finished @ethicnology's task in 7m 48s —— View job Review: refactor(tor): replace legacy Tor integration
SummaryThe deletion is clean. I searched Migration correctness checks that passed:
Findings (all low severity — nothing blocking)1. 2. Stale verify result can overwrite a newer one — 3. 4. The censorship/progress UI added to the status card is unreachable from this screen — None of these should hold up the merge — the stated goal (nothing outside the deleted tree still expects the old types) checks out. |
5eb2411 to
30b6827
Compare
5b93305 to
5d4ebf1
Compare
8007d94 to
98ece4d
Compare
98ece4d to
183a444
Compare
7604345 to
aaefccf
Compare
aaefccf to
4d5e032
Compare
4d5e032 to
8791ad2
Compare
8791ad2 to
34e6357
Compare
Stacked on the
feat/tor-electrumPR. Review that one first.Both Tor consumers now go through
bull_tor, so the old integration has nothing left to serve and is deleted:lib/core/tor/'s socket adapter,tor_connectivity_service,tor_config_adapter,tor_locator,tor_status, the proxy-config value object andcheck_tor_proxy_connection_usecase.That also drops the
tordependency (Foundation-Devices/tor, pinned atb92e2bc) and the Linux plugin registration it brought with it. Net effect on this commit is 514 deletions against 288 insertions.The Tor settings screen moves onto the new contract: the cubit reads connection state from
bull_tor, andtor_connection_status_cardreports what the new state machine can actually express instead of the old boolean-ish status.This is the PR where the migration becomes irreversible, so it is worth checking that nothing outside the deleted tree still expects the old types — whole-project analyze covers that, and it is clean.