Skip to content

fix(ble): stop the 5/MG history auto-continue at 0 pages behind (experimental, untested on a strap) - #2823

Open
LeonardSEO wants to merge 1 commit into
ryanbr:mainfrom
LeonardSEO:fix/5mg-autocontinue-zero-pages
Open

LeonardSEO wants to merge 1 commit into
ryanbr:mainfrom
LeonardSEO:fix/5mg-autocontinue-zero-pages

Conversation

@LeonardSEO

Copy link
Copy Markdown

Experimental: not tested on a strap. I am opening it because the change is small and reversible, but I do not expect it to be merged before someone confirms it on a 5/MG.

What this PR does

On a WHOOP 5/MG, shouldAutoContinue never sees a strap timestamp (a 5/MG GET_DATA_RANGE reply carries none in the place the 4.0 path scans), so the drain relies on branch 2b ("rows were persisted") alone and keeps re-kicking until the cap. The strap does report its ring backlog, pagesBehind, which is already decoded but diagnostic only.

Source: the observation that the official app re-queries GET_DATA_RANGE before every history round (about every 600 s in an overnight iOS capture) comes from LeonardSEO/wearable5.0 (FINDINGS §3 and §10), an independent 5/MG protocol library built on NOOP's protocol docs.

Type of change

  • Bug fix

How it was tested

  • BackfillContinuationTests / BackfillContinuationTest: 0 pages behind stops, a backlog or no reading keeps today's decision.
  • ./gradlew testFullDebugUnitTest: 6689 tests, all pass apart from the 2 RecoveryDriversTest half-tie cases that fail the same way on unmodified main.
  • Tools/i18n_audit.py --ci, Tools/doc_comment_lint.py, docs/protocol-examples checks and Tools/parity_ledger.py --refresh-derived (derived snapshots included): pass.
  • Tools unit tests, the parity acceptance suite and the R-R contract: pass apart from the 4 test_check_source_references cases (/var vs /private/var temp path on macOS) that fail the same way on unmodified main.
  • Apple: the macOS app (Strand) builds with this change on my development branch; StrandTests and the iOS target were not run locally for this branch. app-build.yml covers both.

Not tested on hardware. I do not have a 5/MG strap for this. What would confirm it: a 5/MG strap log with a deep backlog showing the drain ending on the new line once Strap backlog pages behind: 0 is logged, instead of running to the cap.

Checklist

  • Swift package tests pass for any package I touched (none touched)
  • Android unit tests pass if I touched android/ (apart from the 2 RecoveryDriversTest half-tie cases that fail the same way on unmodified main)
  • No new build warnings introduced (Android: none; Apple warnings not checked per branch)
  • UI changes use only StrandDesign / Palette / Metrics tokens
  • No hardcoded hex frame bytes; protocol facts live in the schema / decoders
  • Follows the conventions in docs/CONTRIBUTING.md
  • I did not commit generated output (Strand.xcodeproj/) or any secrets/keystores

Related issues

Refs #1992

🤖 Generated with Claude Code

…es behind

shouldAutoContinue takes the pages-behind value read at the start of the pass and stops at 0; nil keeps the existing behaviour. Apple re-reads GET_DATA_RANGE before each 5/MG continuation pass, as the official app does before every history round (observation from LeonardSEO/wearable5.0 FINDINGS §10). Not tested on a strap.

Refs ryanbr#1992
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant