RomanNum3ral
/
paperclip
mirror of https://github.com/paperclipai/paperclip.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

test(ui): wait for the route, not three turns, in the cases-routing test (#11521) 

The instance #11499 named but did not include. `App.cases-routing.test.tsx`
carried the identical fixed-turn loop that PR replaced in its sibling
`App.activity-routing.test.tsx` - three macrotasks instead of five, otherwise
the same helper - so it fails the same way when the suite runs many workers in
parallel and the container has not filled yet. It was one of the failures
observed while verifying #11499.

Same one-line replacement: `vi.waitFor` retries against a time budget, so a
loaded worker gets more turns rather than a failure. The two helpers are
identical again.

Verified on the mechanism rather than on a green run, because the old loop
passes in isolation too - that is what made this a flake and not a failure. A
throwaway probe drove both helpers against a container whose text lands after
ten macrotasks: the three-turn loop throws, `vi.waitFor` resolves. That is the
condition a loaded CI worker creates. The probe was deleted rather than
committed; it tests a test helper and had one question to answer.

This closes one named instance, not the class. The full ui suite passed three
consecutive times with no failure in any file, but the other instances seen
during #11499's verification - TaskChatComposer, RequestCollapsedSidebar -
simply did not recur, so they are rarer rather than fixed. Refs #11484.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Tonio 2026-08-17 00:42:54 -07:00 committed by GitHub
parent e07d605dfc
commit 65907aa41f
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 12 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
ui/src/App.cases-routing.test.tsx
View File

@ -100,12 +100,19 @@ async function renderAppAt(container: HTMLElement, path: string) {
return root;
}
/**
* Waits on the condition, not on a fixed number of turns. The previous version
* yielded at most three macrotasks before asserting, which is ample on an idle
* machine and not when the suite is running many workers in parallel — the
* container was still empty and the assertion failed on a route that resolves
* perfectly well. `vi.waitFor` retries against a time budget instead, so a
* loaded worker gets more turns rather than a failure.
*
* The same fix #11499 applied to the sibling `App.activity-routing.test.tsx`,
* which had the identical loop with five turns instead of three.
*/
async function waitForRoute(container: HTMLElement, text: string) {
for (let attempt = 0; attempt < 3; attempt += 1) {
if (container.textContent?.includes(text)) return;
await new Promise((resolve) => window.setTimeout(resolve, 0));
}
expect(container.textContent).toContain(text);
await vi.waitFor(() => expect(container.textContent).toContain(text));
}
describe("App Cases routing (PAP-13002)", () => {