test(e2e): wait for the dashboard before asserting the disabled rail

"hides an individually disabled dashboard rail while dashboard remains
enabled" asserted right after the URL changed to /workspace/dashboard.
The settings view could still be mounted then, so the "Dashboard" link
lookup matched both the rail link and the settings page's Dashboard
section link (strict-mode violation), and the rail check could pass
before the dashboard had rendered at all. Failed on macOS CI and locally
on master too (1 in 5), so it is a pre-existing race.

Wait for the dashboard page to be attached (the fixture's dashboard is
empty once its only populated rail is off, so it has no size) and for
the settings section link to be gone before asserting.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
4grayandClaude Opus 5.5 committed 2026-09-27 03:31:29 +02:00
1 parent ce50866481
commit e11d54cbae
1 file changed
+12
@@ -699,6 +699,18 @@ test.describe('Electron Settings', () => {
await goToDashboard(app.mainWindow);
await app.mainWindow.waitForURL(/\/workspace\/dashboard$/);
// The URL changes before the settings view is torn down and the
// dashboard renders. Wait for the dashboard itself, or the rail
// check passes vacuously and the "Dashboard" link below also
// matches the settings page's own "Dashboard" section link.
// Attached, not visible: with its only populated rail disabled
// the fixture's dashboard is empty and has no size.
await expect(
app.mainWindow.getByTestId('dashboard-page')
).toBeAttached({ timeout: 20000 });
await expect(
app.mainWindow.getByTestId('settings-section-dashboard')
).toHaveCount(0);
await expect(
app.mainWindow.getByTestId('dashboard-recent-sources-rail')
).toHaveCount(0);