fix: adopt already-connected peripheral instead of stranding at "(Pairing…)"#39
Merged
Merged
Conversation
…ring…)" The auto-reconnect watcher's reclaim path does a HOLDS_ONE network round-trip to the peer before deciding to re-pair. macOS often reconnects the bonded device on its own during that window, so by the time connectPeripheral runs the device is already connected. Starting an IOBluetoothDevicePair on an already-connected device never fires devicePairingFinished, stranding the state machine at .connecting — the menu shows "(Pairing…)" forever even though the peripheral works. Short-circuit in connectPeripheral: if the device is already connected, adopt the live connection (set .connected, register the disconnect observer) instead of pairing. Covers the interactive take/menu paths too.
|
🎉 This PR is included in version 2.11.2 🎉 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
The auto-reconnect watcher (#36) can leave a peripheral stuck showing (Pairing…) in the menu forever, even though it is actually connected and working.
The reclaim path (
reclaimIfPeerIsFree) does aHOLDS_ONEnetwork round-trip to the peer before deciding to re-pair. During that window macOS frequently reconnects the bonded device on its own. By the timeconnectPeripheralruns, the device is already connected — butconnectPeripheralonly checked Bluetooth power and RSSI, neverisConnected(), so it still started anIOBluetoothDevicePair. Pairing an already-connected device never firesdevicePairingFinished, so the state machine is stranded at.connecting.Fix
Short-circuit in
connectPeripheral: if the device is already connected, adopt the live connection (set.connected, register the disconnect observer so a future genuine drop re-arms the watcher) instead of pairing. The watcher then disarms on its next tick.Placing the check in
connectPeripheralrather than just the watcher path also protects the interactivetakePeripheralFromPeer/ per-peripheral menu paths from the same stranding.Testing
xcodebuild ... CODE_SIGNING_ALLOWED=NO buildsucceeds.swift formatleaves the change untouched.