HRV and Charge stop at an R-R boundary while HR, sleep and RHR continue past it

[ryanbr]

Observation

On a 5/MG install, a full 21-night re-score produces HRV and Charge for only the most recent eleven nights, while sleep and resting HR reach the whole window. The census line is stable across consecutive passes:

re-score census: 21 night(s) 2026-09-01..2026-09-21 charge=11 effort=14 sleep=20 hrv=11 rhr=20

The eleven nights carrying HRV are contiguous and are the newest eleven. Every night older than that boundary has no HRV, and therefore no Charge.

What the evidence says

R-R is ABSENT before the boundary, not present-and-rejected. The clearest single line, from the same pass:

sleep-detect day=2026-09-07 NO-NIGHT hr=134089 rr=0 resp=0 grav=0 skin=0 steps=0

Abundant heart rate, zero R-R, on a day that sits before the boundary. On the eleven nights after it, R-R beat counts per night run from roughly 3,700 to 23,000, so where R-R exists there is plenty of it.

So HRV and Charge are following R-R availability. That part is not in question.

What is ruled out

Two plausible explanations were checked and do not hold:

• Not a quality gate. HRVAnalyzer only gates on the two OVER-COUNT verdicts; underCovered and unmeasurable stay trusted (HRVAnalyzer.swift:422, :436). Most of the nights that DO produce HRV read underCovered, so that verdict plainly is not what removes a night.
• Not age-based retention. The only R-R prune is pruneRrByTs, called from WhoopRepository with a plausibility window of MIN_PLAUSIBLE_UNIX through now + futureMargin. It removes implausible timestamps, not old rows.

What is NOT established

Why R-R stops at that boundary while heart rate continues through it. The install has two registered straps, a 5/MG active and a 4.0 last seen a fortnight ago, so a handover between sources is one candidate, and a capture path that only began storing R-R later is another. Nothing in the log distinguishes them, and this issue deliberately does not pick one.

What would discriminate

A single store query settles the first fork: do rr rows exist for the days before the boundary under EITHER device id?

• No rows at all means R-R was never captured for those days, and the question becomes which source was writing heart rate for them and why it carried no R-R.
• Rows present means they are being captured but not reaching the analyzer, and the question moves to the read path and its device-id scoping.

Worth running that before anyone changes a threshold or a window.

Why it matters

Charge depends on HRV, so a user with more history than the R-R boundary sees roughly half their recovery scores silently absent, with the census line reporting it as "the pass produced nothing for" rather than as a missing input. That reads like a scoring fault when the inputs are the thing that is missing.

Filed from a maintainer device log rather than a user report. No biometric values are quoted here, only row counts and dates.

[ryanbr]

A second day's log from the same device narrows this considerably, and rules out one of the two candidates without needing the store query.

Rolling retention is ruled out

The 21-night scoring window advanced by a day. The HRV start did not move with it.

pass	scoring window	nights with HRV	hrv	charge
21 Sep	2026-09-01..2026-09-21	2026-09-11..2026-09-21	11	11
22 Sep	2026-09-02..2026-09-22	2026-09-11..2026-09-22	12	12

Under a rolling retention window the count would have stayed at eleven: the oldest night drops as the newest arrives. Instead the start stayed pinned to 2026-09-11 and the span grew by one. R-R begins at a fixed date and has been continuous since. Charge tracks HRV exactly, both passes, which confirms it is downstream rather than independently short.

The same source produced heart rate without R-R for three days first

The three days between the last sighting of the other strap and the boundary are scored and carry plenty of heart rate:

sleep-motion day=2026-09-08 grav=0 hr=132115
sleep-motion day=2026-09-09 grav=0 hr=184126
sleep-motion day=2026-09-10 grav=0 hr=177198
sleep-motion day=2026-09-11 grav=0 hr=178344      <- R-R starts here
sleep-motion day=2026-09-12 grav=0 hr=186547

Heart-rate volume is comparable either side of the boundary. The registry has the 4.0 at lastSeen=15d ago, which is 2026-09-07, so those three days are not a live second strap. Whatever was writing heart rate on 09-08 through 09-10 wrote no R-R, and then from 09-11 wrote both.

That reframes the question. It is not "which source" so much as "what changed on 2026-09-11 in what gets stored", since the wearing pattern and the heart-rate path look unchanged across it.

Still worth the store query

The discriminator in the original post still applies and is now sharper: are there any rrInterval rows at all before 2026-09-11, under any device id?

• None puts the question entirely on the capture path and on what changed that day.
• Some means they exist and are not reaching the analyzer, which would be a read-path problem and a much more serious one, because it would mean the same is true for anyone else with pre-boundary R-R.

Counts and dates only in this update; no biometric values.

[ryanbr]

Ran the store query. It answers the fork, and the answer is the second branch: the rows are there and are not reaching the analyzer. The mechanism turns out to be known and deliberate, which moves the issue somewhere more useful.

The rows exist, on every day

R-R counts per local day under the ACTIVE strap, from a backup of the affected device (counts only):

2026-09-06  48,985      2026-09-14  55,766
2026-09-07  28,045      2026-09-15  60,379
2026-09-08  60,307      2026-09-16  58,337
2026-09-09  62,780      2026-09-17  61,812
2026-09-10  55,408      2026-09-18  40,047
2026-09-11  62,459  <-  2026-09-19  58,200
2026-09-12  63,742      2026-09-20  61,894
2026-09-13  58,796      2026-09-21  64,278

7.83 million R-R rows in total, earliest 2026-07-07. There is no gap at the boundary. For context the engine reported rr=0 for 2026-09-07 while the store holds roughly 93k rows for that day across both device ids.

What actually discriminates them

srcChannel, and it transitions exactly at the boundary:

2026-09-08   srcChannel = NULL
2026-09-09   srcChannel = NULL
2026-09-10   srcChannel = NULL and 7     <- mixed, the changeover day
2026-09-11   srcChannel = 7              <- first fully tagged day, first day with HRV

tsSuspect is 0 throughout, so that is not involved.

The read explains it. WHOOP5_RR_INTERVALS_SQL pins a window to the lowest scorable channel present:

AND srcChannel = (SELECT MIN(srcChannel) FROM rrInterval
                  WHERE deviceId = :deviceId AND ts >= :from AND ts <= :to
                  AND srcChannel IN (5, 7) ...)

For a window whose rows are all NULL the subquery matches nothing and returns NULL, and srcChannel = NULL is never true in SQL. Zero rows come back. That is the rr=0.

This is designed, not an oversight

The comment on FIRST_RECORDED_RR_SQL names it directly: it exists to separate "history this strap actually recorded" from imported history, because "only the former can have lost anything to a labelling change". R-R banked before the channel labelling existed cannot be scored, and the code knows.

So the defect is not the filter.

The defect is that nobody is told

ConnectionReadout already has the readout for exactly this:

rrTransport <recorded> scorable=none unscorableHistory=yes

It appears zero times across two full multi-session logs from the affected device, the device it exists to explain. Nothing in either log mentions unscorable history, a labelling change, or a date on which scoring begins.

What the wearer gets instead is the census line, which attributes the shortfall to the pass:

21 night(s) 2026-09-02..2026-09-22 charge=12 effort=14 sleep=20 hrv=12 rhr=20
(a metric short of the night count is one the pass produced nothing for)

Roughly half their Charge history is absent, the store holds the inputs, the reason is known to the code, and no readout says so. That is the thing worth changing.

Two follow-on questions, not answered here

• Why the readout does not fire. Whether it is gated, unreached on this path, or emitted somewhere the log does not carry.
• Whether the old rows can be promoted. PROMOTE_WHOOP5_RR_SOURCE_SQL exists and moves NULL to 5 or 7, but it is keyed on an exact row identity, so it looks like a per-row promotion when a labelled duplicate arrives rather than a bulk backfill. Whether untagged history can be relabelled wholesale is a separate question from whether the wearer is told it cannot.

Counts, dates and schema only. No biometric values, and the strap id is truncated as the app's own logs truncate it.