Repository navigation
test(lexitar): stop the leaf-regen spec racing the regen queue's depth - #28
Conversation
The last assertion in shell-leaf-regen.spec.ts gave one treatmentAssessment post a 10 s wall-clock budget, and that budget was competing with the background regen queue rather than with the app. corpus-lane.ts serializes every unprompted regen through a single chained promise - a lane of one, deliberately, because each such request can hold tens of megabytes of corpus in one Pages Function isolate - and a fresh patient opens with every node stale, so each save in this test queues a sweep ahead of the next one. By the final save the lane is deep, and it drains at whatever rate the machine is loaded at. Measured rather than guessed: the same commit failed this poll once in CI and once in a local full-suite run, and passed in CI and locally on the next run with no code change in between. It also passes every time the file is run alone, which is the queue being shallow rather than the logic being different. So wait for the queue to go quiet - no new post for a second - and only then measure. The poll after it is now a measurement of one round trip, which is what it was written to assert, and the final `groupPosts() === 1` gets stricter rather than looser: a second treatmentGroups arriving late would previously have landed after the assertion read the count. Signed-off-by: Pablo Rodriguez <contact@promontory.studio> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> (cherry picked from commit 4bea70d)
Deploying health-dash-main with
|
| Latest commit: |
dcd1a50
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://f8d49e02.health-dash-prod.pages.dev |
| Branch Preview URL: | https://test-leaf-regen-queue-depth.health-dash-prod.pages.dev |
Deploying health-dash-dev with
|
| Latest commit: |
dcd1a50
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://b195c2aa.health-dash-aex.pages.dev |
| Branch Preview URL: | https://test-leaf-regen-queue-depth.health-dash-aex.pages.dev |
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
There was a problem hiding this comment.
Test-only change; checked the settle helper's logic (first tick always resets, 200 ms intervals, 1 s quiet window, no false-positive on a never-incrementing counter), its placement between the groupPosts==1 assertion and the unrelated-save block, that draining the lane first can't invalidate the later assertions (the mocked {groups: []} merge already lands before the settle, and the final treatmentAssessment check reads treatment history, which background nodes don't touch), and that the corpus-lane.ts rationale in the comment matches the code (lane of one, shared with the corpus warmer). Non-blocking nit: the helper's 45_000 ms poll timeout exceeds the 30_000 ms per-test budget in playwright.config.ts:5, so it can never fire — a queue that never goes quiet will surface as an opaque "Test timeout of 30000ms exceeded" rather than this helper's own failure; worth lowering it (or adding test.setTimeout) so the diagnostic matches the intent.
shell-leaf-regen.spec.ts's last assertion gave onetreatmentAssessmentpost a 10 s wall-clockbudget, and that budget was competing with the background regen queue rather than with the app.
corpus-lane.tsserializes every unprompted regen through a single chained promise — a lane of one,deliberately, because each such request can hold tens of megabytes of corpus in one Pages Function
isolate — and a fresh patient opens with every node stale, so each save in this test queues a sweep
ahead of the next one. By the final save the lane is deep and drains at whatever rate the machine is
loaded at.
Measured rather than guessed. The same commit failed this poll once in CI and once in a local
full-suite run, and passed in CI and locally on the next run with no code change in between. It also
passes every time the file is run alone, which is the queue being shallow rather than the logic being
different.
So wait for the queue to go quiet — no new post for a second — and only then measure. The poll after
it becomes a measurement of one round trip, which is what it was written to assert, and the final
groupPosts() === 1gets stricter rather than looser: a secondtreatmentGroupsarriving latewould previously have landed after the assertion read the count.
Why this branch and not the one the commit was written on. It was held off deliberately so it
could not reset the promotion soak clock a third time, and that promote has now landed
(
tinytars/lexi#27, merged 2026-10-27).fix/dep-bumps-and-port-driftcarried it, but that branchpredates #26 and merging it now would resurrect three deleted documents and revert the About copy
change — so the commit is cherry-picked onto current
devinstead and that stale branch is not theone proposed. One file, 33 lines added, nothing else differs from
dev.🤖 Generated with Claude Code