Fix three more date-boundary flaky asserts in ReadSpineActiveDeviceTests - #609
Merged
Merged
Conversation
Same class as the HugeImportFirstPaintStressTests fix (#607), surfaced now that app-build runs StrandTests: these assert latestDataDayStart() equals the logical day of the seed's FIRST sample (base), but latestDataDayStart resolves to MAX(ts) = the LAST sample (base + N-1). When a seed spans the 04:00 logical-day rollover (e.g. base=03:57 → base+299=04:02), the two land on different days and the assert fails in that window — this run hit it at 05:57 UTC (freshBase = now-2h = 03:57). Assert against the latest sample's day instead: staleBase+299 / freshBase+299 (300-sample seeds) and liveBase+599 (600-sample seed). Test-only; the code is correct (latestDataDayStart rightly returns the newest data's day).
DX23876
pushed a commit
to DX23876/noop
that referenced
this pull request
Jul 22, 2026
…sts (ryanbr#609) Same class as the HugeImportFirstPaintStressTests fix (ryanbr#607), surfaced now that app-build runs StrandTests: these assert latestDataDayStart() equals the logical day of the seed's FIRST sample (base), but latestDataDayStart resolves to MAX(ts) = the LAST sample (base + N-1). When a seed spans the 04:00 logical-day rollover (e.g. base=03:57 → base+299=04:02), the two land on different days and the assert fails in that window — this run hit it at 05:57 UTC (freshBase = now-2h = 03:57). Assert against the latest sample's day instead: staleBase+299 / freshBase+299 (300-sample seeds) and liveBase+599 (600-sample seed). Test-only; the code is correct (latestDataDayStart rightly returns the newest data's day).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Same class as #607's
HugeImportFirstPaintStressTestsfix, surfaced by the same cause: now thatapp-buildruns StrandTests, these latent time-bombs actually execute.The bug
ReadSpineActiveDeviceTestsseeds HR spanning[base, base+N-1]and assertslatestDataDayStart()equalslogicalDayStart(base). ButlatestDataDayStartresolves to MAX(ts) = base+N-1 (the newest sample), not the first. When a seed straddles the 04:00 logical-day rollover,baseandbase+N-1land on different logical days and the assert fails in that window. This run hit it at 05:57 UTC (freshBase = now − 2h = 03:57→freshBase+299 = 04:02), givingexpected 2026-07-18vsactual 2026-07-19.Three asserts affected (lines 45/55/164). The #607 confirming run at 05:05 UTC happened to miss all three; this 05:57 run caught the fresh one — confirming they're wall-clock-flaky.
The fix
Assert against the latest sample's day, matching what the code returns:
staleBase+299/freshBase+299(300-sample seeds),liveBase+599(600-sample seed). Test-only —latestDataDayStartcorrectly returns the newest data's day; the tests were checking the wrong endpoint.Verification
swiftc -parseclean; dispatchedapp-build(which now runs StrandTests) to confirm the suite is green. Note: the flake is wall-clock-dependent, so a single run can't reproduce the boundary window, but the fix makesexpectedequallogicalDayStart(MAX ts)by construction, which is exactly what the read resolves to.