Skip to content

Empty-offload backoff (#1123/#1125) resets on reconnect — should survive it #1148

Closed

Description

@ryanbr

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.

Activity

  1. ryanbr commented on Aug 8, 2026

    @ryanbr
    OwnerAuthor

    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.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions