You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Two intermittently-failing tests observed during work on #1626 (PR #1697). Both pass on re-run; both are timing-sensitive assertions rather than product bugs. Tracking them so they can be stabilized.
1. ViewHeader.test.tsx — "animates the server name and disconnect controls in on connect, out on disconnect (#1450)"
Error: expect(element).not.toBeInTheDocument()
expected document not to contain element, found <button …>
Root cause: the test await waitFor(...)s that the server-name text is removed after its exit Transition, then does a synchronousqueryByRole("button", { name: "Disconnect from server" }) assertion. The server name and the Disconnect button are removed by two independent Mantine Transition exits; on a slow runner the button's exit can lag the name's, so it's still in the DOM at the synchronous check.
Suggested fix: wrap the Disconnect-button "removed" assertion in its own waitFor (like the server-name one), so it doesn't assume the two transitions complete in lockstep.
2. TUI App.test.tsx — "App (OAuth result branches) > completes a standard step-up authorize when OAuth succeeds"
File:clients/tui/__tests__/App.test.tsx
Symptom (seen locally under coverage:tui, i.e. v8-instrumented / slower):
AssertionError: expected '────…' to contain 'Step-up authorization succeeded'
Passed on a plain validate:tui run and on re-run. The assertion reads the Ink frame before the success line has rendered under the slower instrumented run.
Suggested fix: poll/waitFor the Ink lastFrame() for the expected line instead of asserting a single snapshot, or advance timers deterministically.
There is currently no retry configured in any vitest project, so a flake fails the whole CI build job. Consider whether a small retry: 1 on the affected projects is warranted in addition to fixing the assertions (or keep zero-retry and just fix the timing assertions).
Two intermittently-failing tests observed during work on #1626 (PR #1697). Both pass on re-run; both are timing-sensitive assertions rather than product bugs. Tracking them so they can be stabilized.
1.
ViewHeader.test.tsx— "animates the server name and disconnect controls in on connect, out on disconnect (#1450)"File:
clients/web/src/components/groups/ViewHeader/ViewHeader.test.tsx(~line 351–356)Symptom (seen in CI on the
buildjob):Root cause: the test
await waitFor(...)s that the server-name text is removed after its exitTransition, then does a synchronousqueryByRole("button", { name: "Disconnect from server" })assertion. The server name and the Disconnect button are removed by two independent MantineTransitionexits; on a slow runner the button's exit can lag the name's, so it's still in the DOM at the synchronous check.Suggested fix: wrap the Disconnect-button "removed" assertion in its own
waitFor(like the server-name one), so it doesn't assume the two transitions complete in lockstep.2. TUI
App.test.tsx— "App (OAuth result branches) > completes a standard step-up authorize when OAuth succeeds"File:
clients/tui/__tests__/App.test.tsxSymptom (seen locally under
coverage:tui, i.e. v8-instrumented / slower):Passed on a plain
validate:tuirun and on re-run. The assertion reads the Ink frame before the success line has rendered under the slower instrumented run.Suggested fix: poll/
waitForthe InklastFrame()for the expected line instead of asserting a single snapshot, or advance timers deterministically.Notes
retryconfigured in any vitest project, so a flake fails the whole CIbuildjob. Consider whether a smallretry: 1on the affected projects is warranted in addition to fixing the assertions (or keep zero-retry and just fix the timing assertions).