fix(ble): retry a refused pairing scan in seconds, not minutes - #1109
Merged
Merged
Conversation
The scanner role counted a pairing start as begun whenever advertising started, even when the scan itself was refused (Android's 5-per-30 s limit, or the coordinator's 6 s gap between scans). The attempt then sat in WaitingForConnection on a scan that never ran until the 90 s stale window passed, plus up to 30 s for the loop to look again: up to two minutes before a retry. - A refused scan is now a failed start: after 7 s (past the scan gap) the attempt is marked failed and the loop woken, so it starts again at once. - An attempt still waiting for its first connection goes stale after 20 s; a handshake under way keeps 90 s. - The pairing loop looks again every 10 s instead of 30 s. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y4wDTToHmJfkYYJvMKXt3u
Code-only moves. Map built at d39cf96; the evidence each pin names ran at that tree: 36 dsm and 35 dsm_sdk tests, all passing. make requirement-map-intent INTENT_BUILT=android,node: 635 PINNED, 0 failing. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Y4wDTToHmJfkYYJvMKXt3u
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
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.
Summary
Bluetooth pairing after adding a contact could take a minute or two.
Cause: in the scanner role,
start_ble_discoverycounted the start as successful whenever advertising started, even when the scan itself was refused. Scans get refused by Android's 5-starts-per-30 s limit, or byBleCoordinator's 6 s gap between scans. The attempt then sat inWaitingForConnectionwaiting on a scan that never ran. Nothing retried until the 90 s stale window passed, plus up to 30 s more for the pairing loop to look again.Fix (
bluetooth/pairing_orchestrator.rs):after_discovery_start→discovery_refusedmarks an attempt still waiting for its first connection asFailedand wakes the loop, so it starts again at once.stale_after_secs: an attempt waiting for its first connection goes stale after 20 s. A handshake already under way keeps 90 s.Testing
pairing_orchestratortests: 11 pass, 3 of them new-D warnings(dsm_sdk --all-targets);real_code_guard.py;ci/no_clock_and_no_json.shNotes
android_ble_bridge::tests::pairing_smoke_*fail when run on their own ("Storage base directory not set"). They fail the same way onmain, a different one each run, and pass in the full suite. Not touched here.🤖 Generated with Claude Code
https://claude.ai/code/session_01Y4wDTToHmJfkYYJvMKXt3u
Generated by Claude Code