You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Empty-offload backoff (#1123/#1125) resets on reconnect — should survive it #1148
Source: real WHOOP 4.0 capture noop-capture-260808-1527.txt + strap log (9.3.2-staging, 2026-08-08). Companion to #1144.
The #1123/#1125 empty-offload backoff spaces out empties in steady overnight state, but a reconnect resets the streak — and reconnects are frequent (this capture: 4 failedConnect(status147) + 3 connectionTimeout, median connection uptime ~4.4 min during the day). Each reconnect re-armed the empty storm. Persist consecutiveEmptyOffloads / the backoff state across reconnects (per device) so it can't re-arm. Both platforms.
Verified before implementing — the premise doesn't hold; closing.
The empty-offload backoff counters do NOT reset on reconnect on either platform:
consecutiveEmptyOffloads is zeroed only when a banking offload persists rows (WhoopBleClient.kt:6844 / BLEManager.swift:2006), never on connect/disconnect/teardown.
EmptySyncTracker has no reset method and is never recreated (declared once on each platform).
WhoopBleClient/BLEManager are process-lifetime singletons (created once in NoopApplication), so those instance counters survive every reconnect.
emptyStreak = max(consecutiveEmptySyncs, consecutiveEmptyOffloads) therefore stays engaged across reconnects — which is what this issue asked for.
The noon empty-offload storm in the capture was the #1144 auto-continue spin (24 re-kicks/burst, bypassing the periodic floor entirely) — NOT the backoff resetting. #1145 fixed that. The overnight empties in the same capture were correctly spaced (10–35 min apart), confirming the backoff engages and persists across reconnects.
The only state that does NOT survive is an app process kill (the counters are in-memory, not in SharedPreferences) — but that rebuilds in 3 empties and app-kill≠reconnect, so it's marginal and not what this issue described. Closing as already-handled; happy to reopen if a fresh capture shows the backoff actually disengaging across a reconnect.
Activity
ryanbr commentedon Aug 8, 2026
Verified before implementing — the premise doesn't hold; closing.
The empty-offload backoff counters do NOT reset on reconnect on either platform:
consecutiveEmptyOffloadsis zeroed only when a banking offload persists rows (WhoopBleClient.kt:6844/BLEManager.swift:2006), never on connect/disconnect/teardown.EmptySyncTrackerhas no reset method and is never recreated (declared once on each platform).WhoopBleClient/BLEManagerare process-lifetime singletons (created once in NoopApplication), so those instance counters survive every reconnect.emptyStreak = max(consecutiveEmptySyncs, consecutiveEmptyOffloads)therefore stays engaged across reconnects — which is what this issue asked for.The noon empty-offload storm in the capture was the #1144 auto-continue spin (24 re-kicks/burst, bypassing the periodic floor entirely) — NOT the backoff resetting. #1145 fixed that. The overnight empties in the same capture were correctly spaced (10–35 min apart), confirming the backoff engages and persists across reconnects.
The only state that does NOT survive is an app process kill (the counters are in-memory, not in SharedPreferences) — but that rebuilds in 3 empties and app-kill≠reconnect, so it's marginal and not what this issue described. Closing as already-handled; happy to reopen if a fresh capture shows the backoff actually disengaging across a reconnect.