Skip to content

Fix premature WHOOP historical sync completion causing data loss - #2

Merged
BarMal merged 2 commits into
masterfrom
claude/whoop-strap-sync-debug-in8711
Jun 16, 2026
Merged

BarMal merged 2 commits into
masterfrom
claude/whoop-strap-sync-debug-in8711

Conversation

@BarMal

@BarMal BarMal commented Jun 16, 2026

Copy link
Copy Markdown
Owner

The historical backfill was being marked complete as soon as any
realtime data frame (0x28/0x2B) arrived, even though the strap
interleaves realtime HR summary frames with ongoing historical batch
delivery. This caused the sync to disconnect almost immediately after
connecting, before any real historical data was transferred, matching
the observed connect -> packet exchange -> disconnect -> no data
behaviour. The completion signal now relies solely on the strap's
explicit historical-sync-complete metadata marker.

Also close a related race in WhoopRecordingService where the record
collector job was cancelled immediately on stop, potentially dropping
records still sitting in the buffer; it now disconnects first, gives
the collector a moment to drain, then joins the cancellation.

https://claude.ai/code/session_01J194Wop2SixMd1HPS5PbcS

claude added 2 commits June 16, 2026 13:41
The historical backfill was being marked complete as soon as any
realtime data frame (0x28/0x2B) arrived, even though the strap
interleaves realtime HR summary frames with ongoing historical batch
delivery. This caused the sync to disconnect almost immediately after
connecting, before any real historical data was transferred, matching
the observed connect -> packet exchange -> disconnect -> no data
behaviour. The completion signal now relies solely on the strap's
explicit historical-sync-complete metadata marker.

Also close a related race in WhoopRecordingService where the record
collector job was cancelled immediately on stop, potentially dropping
records still sitting in the buffer; it now disconnects first, gives
the collector a moment to drain, then joins the cancellation.

https://claude.ai/code/session_01J194Wop2SixMd1HPS5PbcS
The CI workflow runs `chmod +x ./gradlew` and `./gradlew :app:assembleDebug`,
but the Unix gradlew script was never committed (only gradlew.bat existed),
and gradle-wrapper.jar was excluded via .gitignore with no step in CI to
regenerate it. Every previous run of the Android Debug APK workflow on
master failed at the same chmod step for this reason. Generated the wrapper
files for the gradle-wrapper.properties-pinned version (8.13) and committed
them, which is standard practice for the Gradle wrapper.

https://claude.ai/code/session_01J194Wop2SixMd1HPS5PbcS
@BarMal
BarMal merged commit fb2a8da into master Jun 16, 2026
1 check passed
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.

2 participants