v11.6.0 regression: restored HRV/Recovery data disappears after re-score — RR rows stop being served #2101

Activity

1. rafaelphh

   added

   bugSomething isn't workingSomething isn't working

   on Sep 11, 2026
2. ItsMeDrath commented on Sep 11, 2026

   

   ItsMeDrath

   on Sep 11, 2026

   More actions

   yes 11.6 is causing hrv and breathing rate disapparing issue but if we downgrade to 11.5 both data comes back

   👍React with 👍1Reacted by rafaelphh
3. bhelm commented on Sep 11, 2026

   

   bhelm

   on Sep 11, 2026

   More actions

   I traced this regression across the v11.5.0..v11.6.0 history. The most likely introducing commit is 98975f9 (Correct WHOOP 5 R-R interval units).

   That change intentionally introduced a strict WHOOP 5 R-R read policy: legacy rows remain stored, but unlabelled rows are excluded from scoring because old databases can mix correctly converted standard-BLE milliseconds with incorrectly scaled native interval words. This is a reasonable safety feature in isolation.

   The restore/re-score lifecycle makes its current behavior a regression, however:

   1. A v11.5 backup restores the persisted HRV/Recovery results, so they are initially visible.
   2. The next re-score recognizes the device as WHOOP 5 and applies the new strict source predicate.
   3. The restored legacy R-R rows have no transport label, so the read returns no rows.
   4. HRV becomes unavailable and Recovery then fails with missing input.

   This matches the diagnostic transition in the report (rr[read=493509 served=562898] to rr[read=215 served=0 reuseOff=1). reuseOff=1 appears to describe the sliding-window bypass, not the root cause; the decisive behavior is that the underlying strict WHOOP 5 query no longer serves the restored unlabelled rows.

   So I would classify this as: the legacy-row exclusion is an intentional feature, but losing previously working HRV/Recovery after a supported backup restore is an unintended v11.6.0 regression. Confidence is high (roughly 90–95%); a focused test or bisect using a real v11.5 backup immediately before and after that commit would provide the final proof.
4. bhelm commented on Sep 11, 2026

   

   bhelm

   on Sep 11, 2026

   More actions

   A candidate fix is available in #2115.

   @rafaelphh, would you be willing to test it, ideally while you still have the working v11.5 state or by restoring your known-good v11.5 backup? The intended flow is: restore/open the working data, install a build containing the PR, then let the normal sync/backfill/re-score complete and confirm that the existing HRV and Recovery remain visible.

   Important test boundary: the PR has targeted Android regression coverage and a cross-platform source contract, but it has not yet been tested with a real user .noopbak, on physical WHOOP 5 hardware, or compiled on Apple in this Linux environment. Please do not post personal or raw health data publicly; a simple pass/fail plus the redacted rr[read=... served=... reuseOff=...] and HRV/recovery transition is enough.

   The fix does not reinterpret or convert ambiguous legacy R-R rows. It preserves the previously computed HRV/Recovery pair until a labelled scoring transport arrives. If 11.6.0 has already cleared the values, an older backup or a new labelled strap offload is still required.
5. ryanbr commented on Sep 12, 2026

   

   ryanbr

   on Sep 12, 2026

   Owner

   More actions

   The fix is merged and now in a build you can install: the testing-latest staging release, build 492, base 11.6.0, built from 0b0d206.

   Thanks @bhelm for the trace and the fix, @rafaelphh for a report that carried its own proof, and @ItsMeDrath for confirming it independently. Three separate people landing on the same signature is what made this quick to place.

   What the fix does

   11.6.0 correctly stops scoring ambiguous unlabelled WHOOP 5 R-R rows, but the re-score then replaced the previously computed values with null. An existing HRV and Recovery pair is now preserved as an opaque snapshot, and only when the exact scoring window holds valid unlabelled legacy rows and no scorable labelled transport. Every other daily field is still freshly computed, and a labelled transport ends the protection, including when it is too sparse to produce HRV, because that is a real answer rather than an absence.

   Nothing reinterprets or relabels the old rows. That was deliberate rather than conservative for its own sake: legacy rows mix units and origins, the discriminator is exactly the label that is missing, and HRV is built from successive differences, so splicing two scales fabricates a difference that never happened and feeds it to Recovery. A wrong number would be worse than a blank.

   Two things to know before testing

   Breathing rate is NOT covered, and that is now tracked in #2123. It dies from the same cause, since a WHOOP night derives respiratory rate from R-R through the RSA path with no vendor-measured alternative, but the preserved snapshot carries only HRV and Recovery. So on this build expect HRV and Recovery back and respiratory rate still blank. @ItsMeDrath and one other reporter both named breathing rate, so I would rather say that plainly than have it read as the fix half-working.

   Values already cleared by an 11.6.0 re-score do not come back. The fix preserves what is there; it cannot reconstruct what is gone. If your values were already lost, you need an older backup or a fresh labelled strap offload. "Update and it returns" is the natural assumption and it is not what happens.

   What would help

   @rafaelphh, you are best placed since you still have a working 11.5 state: restore your known-good backup on this build, let a normal sync, backfill and re-score complete, and confirm HRV and Recovery survive it. The redacted rr[read=... served=... reuseOff=...] line plus the HRV and recovery transition is enough, and please keep raw health data off a public issue.

   This has not been tested against a real .noopbak on physical WHOOP 5 hardware by anyone yet, which is the one gap between "the tests pass" and "this works". Leaving the issue open until someone confirms it on a real device.
6. rafaelphh commented on Sep 12, 2026

   

   rafaelphh

   on Sep 12, 2026

   Last edited by rafaelphh

   Author

   More actions

   @ryanbr Tested on physical WHOOP 5 / iOS using the requested 11.6.0 staging build.

   I restored the known-good v11.5 backup, then allowed normal sync, historical backfill and multiple re-scores to complete.

   Immediately after restore:

   • HRV: 77 ms
   • Recovery: 59%

   After sync/backfill/re-score completed:

   • HRV: 59 ms
   • Recovery: 9%

   R-R diagnostic after re-score:

   rr[read=895 served=0 truncated=0 ownerFlips=0 reuseOff=1]

   So HRV and Recovery no longer disappear to null/blank, but the restored HRV/Recovery pair was not preserved unchanged after re-score.

   I can provide additional redacted diagnostics privately if needed.
   
   
7. ryanbr commented on Sep 12, 2026

   

   ryanbr

   on Sep 12, 2026

   Owner

   More actions

   Thank you @rafaelphh, that is the exact gap I named and you closed it: a real .noopbak on physical WHOOP 5 hardware. It also produced a more useful result than a pass would have.

   The reported regression is resolved

   HRV no longer goes to "-", Recovery no longer disappears, and Charge no longer drops to "Calibrating, 0 of 4". The destructive nil overwrite is gone.

   What you saw instead is a different problem

   The pair changed rather than survived, and the preserved snapshot was meant to be exact.

   First, one clarification about the line you posted, because it is easy to read as the smoking gun and is not quite:

   rr[read=895 served=0 truncated=0 ownerFlips=0 reuseOff=1]
   

   That is the analyzeRecent sliding-window plan, not the per-night scoring read. served=0 there means no R-R reached the rolling re-score at all, which is exactly the condition the preservation requires, so on that evidence the pair should have come back untouched. It did not, so one of two things happened:

   1. Protection ended, by design. It stops the moment a labelled transport exists in the window. You were syncing a live WHOOP 5, so a labelled offload landing in that window legitimately hands scoring back to freshly computed values.
   2. The day on screen is not the day that was snapshotted. Today shows the most recent night carrying a value, so a freshly scored earlier night can be what you are looking at.

   Both end in the same place: the 59 ms you are seeing is most likely a real, freshly computed number, not a corrupted one.

   Which makes the Recovery figure the more interesting half

   Recovery moving from 59% to 9% is a much larger swing than HRV moving from 77 to 59 accounts for on its own, and that gap points somewhere the preservation work never reached.

   Charge scores a night against a baseline folded over your stored HRV history. After the 11.6.0 unit correction that history can hold values computed under two different unit interpretations: older nights from rows of uncertain scale, newer nights from labelled rows of known scale. A correctly scaled HRV judged against a baseline built mostly from the other scale reads as a collapse. @bhelm's own trace describes the mixture ("correctly converted standard-BLE milliseconds with incorrectly scaled native interval words"), and #459 already documented this exact shape for a different cause, where a straddling window "reads the first nights as suppressed against an inflated mean, a device artifact, not physiology".

   If that is what is happening, the individual numbers are each defensible and the comparison between them is not, which produces a wrong score rather than a blank one. That is the outcome the strict read policy exists to avoid, so it is worth getting right rather than tuning away.

   I have opened #2126 for it with a proposed approach, since it is structural, it outlives the preservation work, and it affects any WHOOP 5 user whose history straddles the upgrade, with no backup involved at all.

   Two things that would settle it

   Both are cheap and neither needs health data:

   1. Which night the displayed HRV belongs to. Last night, or an older one? That alone separates the two mechanisms above.
   2. The rrTransport line from Test Centre, added in diag: say whether a device R-R beats were never banked or were refused by the unit policy #2118 for this exact question:
      rrTransport recorded=... scorable=... unscorableHistory=... gapDays=...
      It says whether a labelled transport has arrived and when the first scorable beat was banked, which is the boundary the whole thing turns on.

   Please keep raw health data and full exports off the issue; those two lines plus a pass or fail is enough. If something genuinely needs more detail, say so here and we will find a better channel for it than a public thread.

   Leaving this open. The original symptom is handled, the follow-up belongs to #2126, and I would rather this stayed open until you can confirm which of the two mechanisms you hit.
8. rafaelphh commented on Sep 12, 2026

   

   rafaelphh

   on Sep 12, 2026

   Author

   More actions

   @ryanbr Confirmed the displayed post-rescore values are for 2026-09-11:

   • HRV: 59 ms
   • Recovery: 9%

   New rrTransport diagnostic from the current staging build:

   rrTransport recorded=2026-08-31 15:07:08 scorable=2026-09-11 14:27:58 unscorableHistory=yes gapDays=11

   The export was taken after a completed re-score of 13 nights.

   I’m keeping the full diagnostic bundle off the public issue as requested.
9. ItsMeDrath commented on Sep 15, 2026

   

   ItsMeDrath

   on Sep 15, 2026

   More actions

   @bhelm @rafaelphh @ryanbr
   Tested this on 11.7.0 upgrading directly from a working 11.5 state, but the issue is still present.Upon opening 11.7.0, HRV and Breathing Rate briefly display on startup, but vanish to null after a few seconds when the background re-score runs (even when tested offline / with Bluetooth off).Downgrading back to 11.5 immediately restores all historical HRV and BR metrics without needing to restore from a backup, confirming the underlying raw $R\text{-}R$ data in the local database is intact. The snapshot preservation logic in 11.7.0 still appears to be triggering a re-score pass that overwrites these fields for my dataset.