app-build: run StrandTests on the macOS Strand leg + fix the flaky test it surfaced - #607
Merged
Conversation
…ate) app-build.yml was compile-only, so the app-target unit tests (StrandTests — backfill-continuation, scheduled-report/strain-target policy, the extended- battery formatter twin, etc.) never ran anywhere: swift-packages can't reach them and this was build-only. Add a macOS-only test step (StrandTests is hosted in the macOS app; NOOPiOS stays compile-only) with a concrete runnable destination. On-demand, same as the rest of this workflow.
Surfaced the moment app-build began running StrandTests: the test seeds today's dense HR over [now-3600, now-1] and asserts latestDataDayStart() equals the logical day of now-3600 — but that earliest sample falls in the PREVIOUS logical day across the 04:00 rollover, so it failed in the 04:00-05:00 window (the run hit 04:49 UTC). MAX(ts)/latestDataDayStart resolves to the LATEST sample's day (≈ now), so assert against that. Test-only; the code is correct.
ryanbr
added a commit
that referenced
this pull request
Jul 19, 2026
…sts (#609) 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
…st it surfaced (ryanbr#607) * app-build: run StrandTests on the macOS Strand leg (app-target test gate) app-build.yml was compile-only, so the app-target unit tests (StrandTests — backfill-continuation, scheduled-report/strain-target policy, the extended- battery formatter twin, etc.) never ran anywhere: swift-packages can't reach them and this was build-only. Add a macOS-only test step (StrandTests is hosted in the macOS app; NOOPiOS stays compile-only) with a concrete runnable destination. On-demand, same as the rest of this workflow. * Fix flaky date-boundary assert in HugeImportFirstPaintStressTests Surfaced the moment app-build began running StrandTests: the test seeds today's dense HR over [now-3600, now-1] and asserts latestDataDayStart() equals the logical day of now-3600 — but that earliest sample falls in the PREVIOUS logical day across the 04:00 rollover, so it failed in the 04:00-05:00 window (the run hit 04:49 UTC). MAX(ts)/latestDataDayStart resolves to the LATEST sample's day (≈ now), so assert against that. Test-only; the code is correct.
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).
DX23876
added a commit
to DX23876/noop
that referenced
this pull request
Aug 1, 2026
…s never runs The table claimed `app-build.yml` runs automatically on PR/push and called `docs/CONTRIBUTING.md`'s "disabled by design" description stale. It is the other way round: `gh workflow list` reports the workflow as `disabled_manually` and its last run was 2026-07-21, while CONTRIBUTING is correct. The `pull_request`/`push` triggers are still in the file, which is exactly what makes the mistake easy — a disabled workflow looks live in the repo and nothing in-tree contradicts it. The consequence is worth stating plainly rather than leaving implicit: `app-build.yml` is the only place `StrandTests` runs (ryanbr#607), so with it off, app-target logic tests are gated by nobody. `CoachMemoryDedupTests` was broken on 2026-07-28 and sat red on `main` until now — cited as the concrete case. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
Re-opened from #606 on a non-
ci/branch (the app-buildcleanupjob auto-deletesci/-prefixed branches, which broke #606's head ref mid-merge).Two changes
app-build.yml: run StrandTests on the macOS Strand leg. The workflow was compile-only, so the app-target unit tests inStrandTestsnever ran anywhere (swift-packagesonly coversPackages/**). Adds a macOS-onlyxcodebuild -scheme Strand -destination 'platform=macOS' teststep; NOOPiOS stays compile-only. On-demand, like the rest of this disabled-by-default workflow.HugeImportFirstPaintStressTests.testLatestDataLookupResolvesWithoutLoadingHistoryassertedlatestDataDayStart()equals the logical day ofnow−3600— but the seed spans[now−3600, now−1], andnow−3600falls in the PREVIOUS logical day across the 04:00 rollover, so it failed in the 04:00–05:00 window (the run hit 04:49 UTC).MAX(ts)/latestDataDayStartresolves to the LATEST sample's day (≈now); assert against that. Test-only — the code is correct.Verification
Dispatched app-build with the test step: it executed 918 StrandTests, 917 passed + the 1 flaky failure, then with the fix all green (run 29674198115, all legs success). This is the first time the app-target test suite has ever run in CI — it validates the pure app-target logic tests (backfill continuation #594, strain-target policy #597, etc.) that had been merged compiled-but-never-run.