fix: keep auto-reconnect probes off the switch rate limiter and untrusted peers - #45
Merged
Merged
Conversation
…sted peers The auto-reconnect watcher's read-only HOLDS_ONE probes now opt out of the OutboundRateLimiter (countsTowardRateLimit: false, threaded through executeHoldsOne) so a run of them — a down peer, or several peripherals recovering at once — can't trip the limiter that gates a user-initiated switch's preflight ping. This mirrors the reachability poll's existing exemption. Both probe sites (reclaimIfPeerIsFree and the wake-time reclaim) also now require device.pendingFingerprint == nil, so a TOFU-mismatched peer is treated as 'no trusted peer': the peripheral is reclaimed locally instead of probing a flagged identity with our stale key (which would auth-fail into the peer's inbound limiter).
|
🎉 This PR is included in version 2.14.1 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up extending the same outbound-rate-limiter decoupling from #44 to the auto-reconnect watcher's read-only
HOLDS_ONEprobes (fired every ~5s while recovering a dropped peripheral, so the watcher never yanks a peripheral the peer is actively using).Don't let background probes trip the switch rate limiter
HOLDS_ONEfed the sharedOutboundRateLimiter, so a run of failing probes — a down peer, or several peripherals recovering at once — could trip it and fail-fast a user-initiated switch's preflight.ping(the row greys / the switch is rejected). ThreadscountsTowardRateLimit: falsethroughexecuteHoldsOneso these fixed-cadence probes opt out, exactly as the reachability poll already does. Safe: the watcher's own bounds (in-flight guard, 5s timer, 600s give-up, post-failure local reconnect) already throttle it, and the outbound limiter is client-side back-off, not the security boundary.Don't probe TOFU-mismatched peers
Both probe sites (
reclaimIfPeerIsFreeand the wake-time reclaim) consultednetworkDevices.firstunconditionally, so a peer flagged as an identity mismatch (pendingFingerprintset) still got probed with our stale key — auth-failing into the peer's inbound rate limiter and reaching out to an identity TOFU exists to quarantine. Gates both onpendingFingerprint == nil, folding the mismatch into the existing "no trusted peer → reclaim locally" branch (the safe default for an untrusted peer).Foreground switches were already guarded at the UI layer (
isSwitchablecheckspendingFingerprint) and the reachability poll already guards both ways — this just makes the background watcher consistent with them.Builds on the
countsTowardRateLimitplumbing from #44 (now onmain); rebased ontomainso the diff is just these two watcher fixes.