[ryanbr]

From the log on #2073.

The problem the line could not answer

That install re-scores 21 nights every 15 minutes, and the day cache reused nothing on 13 of 17 passes:

analyzeRecent dayCache reused=0/21   ×13
analyzeRecent dayCache reused=20/21  ×4
analyzeRecent stepsMotion reused=58-60/60   <- same passes, different cache

Each total miss costs prep≈50s and hr[read=1752302] , 1.75 million rows, on battery. Passes ran 95 to 195 seconds. The steps cache reusing 58-60 of 60 in those same passes rules out general store slowness: it is this cache's key. For scale, a log from the same reporter on an older build scored the same 21 nights in 16.5 seconds.

The reuse count alone cannot say which bug that is. A healthy pass reuses all but today, whose heart rate is still growing, and 20/21 is exactly that. Reusing nothing means something shared by every day's key moved, which is a different fault with a different fix.

What the line says now

Keys are owner|hrCount:hrMaxTs:anchor:detail|streams, so the segment that differs names the cause:

analyzeRecent dayCache reused=0/21 size=21 days=21 missBy=rrAlias5:21

rrAlias5 gets its own answer because it is the one input computed once per pass and folded into all 21 keys, so a single flip is a total miss. owner likewise moves every day at once. hr is the healthy per-day case. That distinction is the whole point: one more log from the reporter now names the culprit instead of narrowing it.

The same treatment for the windows line, from the same log

analyzeRecent windows hr[read=1752302 served=1926517 truncated=0] rr[read=9044 served=0 truncated=0]

A stream that reads rows and serves none is declining, and WindowedStreamPlan's own doc already names the three ways that happens: truncation, an owner flip, or a gap. truncated was already on the line, so counting owner flips separates the other two instead of leaving them as one unanswerable number:

rr[read=9044 served=0 truncated=0 ownerFlips=20]

But that stream needed a fourth answer the doc does not list, and getting it wrong was easy. A WHOOP 5 R-R read passes allowReuse = false, because transport selection is range-dependent and a slice could mix transports:

allowReuse = !repo.isWhoop5RrSource(owner, unlabelledAliasOfWhoop5)

So that window can never serve from its buffer and served=0 there is by design. ownerFlips alone would have read 0 on exactly that stream, since the bypass returns before the comparison and clears the buffer on the way, and a reader would have concluded "a gap" when the truth is the opposite. The line carries reuseOff too:

rr[read=9044 served=0 truncated=0 ownerFlips=0 reuseOff=21]

Together they say which of the four it is. And where both missBy=owner and a non-zero ownerFlips appear on a stream that IS allowed to reuse, the day owner is moving between passes and that is the whole answer for the cache thrash as well.

Two causes that have no key to compare

The engine drops the WHOLE cache when its pass-global config signature changes, and a night that was never cached has nothing to compare either. Tallying only key differences would have left both silent, so the very case this exists to explain, reusing nothing, could still have printed no cause at all. They report as configDropped and absent.

The bytecode ratchet, which shaped the implementation

analyzeRecentOnCpu sits on a JaCoCo budget and my first two drafts failed it (55,996 and 55,930 against 55,700). Rather than raise the ratchet:

• the tally is a field, not a local, so neither its declaration nor the parameter passing lands in the method
• the key compare is folded into the cache lookup (reusableDayScan) instead of added beside it, so it REPLACES the null check and key comparison that used to be inline

Net result 55,605 against the 55,700 budget, smaller than before this change.

Detail

Sorted rather than insertion order: which cause is seen first depends on which day missed first, and a diagnostic that reorders itself between passes is harder to diff. Both platforms produce the same string.

Scope

Diagnostic only. Nothing about what invalidates a night changes, so the cost this exists to explain is untouched and #2073's performance question stays open. I did not want to guess at a cache-key fix when the suspect is an external contributor's correctness change (#2046) and a wrong guess either reintroduces stale scores or hides the real cause.

Verification

Android with --no-build-cache: compileFullDebugKotlin, syncRoomSchemaSnapshot in its own invocation, the full testFullDebugUnitTest including the JaCoCo budget test, doc_comment_lint.py, i18n_audit.py --ci. New Android tests 5 of 5.

The Swift half runs locally, unusually for this repo, because the cache lives in StrandAnalytics rather than the app target: swift test --filter DayCacheMissReasonTests with the docs/BUILD.md snapshot-SQLite flags, 5 of 5 executed.