fix: always check the peer (HOLDS_ONE) before reclaiming, even when bonded#41
Merged
Merged
Conversation
…onded #40 let the auto-reconnect watcher skip the HOLDS_ONE peer check for a peripheral still bonded to this Mac, on the premise that "the peer can't hold a device whose link key lives here." That premise is wrong: Apple's Magic devices remember multiple hosts and stay bonded to *both* Macs (the README's setup step pairs each peripheral to both), so being paired here says nothing about which Mac is currently connected. The regression: if this Mac drops/sleeps while holding a peripheral and the peer takes it during the downtime (the peer can't reach a sleeping Mac to make it `-remove`, so the bond persists here), this Mac would wake and reconnect-reclaim it without asking — yanking it back from the peer that legitimately holds it. Revert the skip so every reclaim goes through `reclaimIfPeerIsFree` first. The gentle reconnect from #40 stays (connectPeripheral opens the connection instead of re-pairing a bonded device), but it now only runs after HOLDS_ONE confirms the peer is free — which is what actually fixed the reported re-pair/disconnect loop.
|
🎉 This PR is included in version 2.11.4 🎉 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.
Problem (regression from #40)
#40 let the auto-reconnect watcher skip the
HOLDS_ONEpeer check for a peripheral still bonded to this Mac, on the premise that "the peer can'''t hold a device whose link key lives here."That premise is wrong. Apple'''s Magic devices remember multiple hosts and stay bonded to both Macs at once (the README'''s setup step pairs each peripheral to both, and they only connect to one at a time). So
isPaired()being true here says nothing about which Mac is currently connected.The hole this opened
releaseOnSleepoff, or no active peer at sleep time) — so it stays bonded.-remove, so it pairs locally — and this Mac'''s bond persists.Answering the actual question that surfaced this: before reclaiming, does it check whether the peer claimed the peripheral? — after #40 the answer was "no, not when bonded." It should always be "yes."
Fix
Revert the bonded-device skip so every reclaim goes through
reclaimIfPeerIsFree→HOLDS_ONEfirst. The gentle reconnect from #40 stays:connectPeripheralstill opens the connection instead of re-pairing a bonded device (that is what fixed the original re-pair/disconnect loop), but it now only runs after the peer confirms it isn'''t holding the peripheral.Testing
xcodebuild ... CODE_SIGNING_ALLOWED=NO buildsucceeds;swift format lintclean.HOLDS_ONEsuccess → this Mac stands down instead of stealing it.