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
test(e2e): split persistence-vs-renderer for restore-on-relaunch flake
The restore-on-relaunch test has been failing on CI for weeks. Bumping the visibility timeout (30s → 60s → 90s) only kicks the can — the test ran past 90s on the latest CI and timed out the same way.
Two things this commit does to make the failure actionable next time:
1. Check that h1 actually persisted `workspaces.json` to disk BEFORE launching h2. If the file isn't there, fail with the userDataDir listing — that's a clear "persistence broke" signal. If the file is there but the renderer in h2 doesn't see it, that points at the renderer-hydrate path instead. The two failure modes have been indistinguishable from the same "button not visible" error to date.
2. Replace the cold `toBeVisible({ timeout: 90s })` with a waitForFunction polling the e2e seam for `store.workspaces.length > 0`. The button is downstream of the store, so polling the upstream signal lets the downstream assertion run at the normal 15s timeout. waitForFunction also throws with a more specific timeout error if hydrate genuinely never fires.
Wrapped the downstream assertions in a try/catch that logs the renderer's storeState, body innerText, and open dialogs on failure. The diagnostic dump lets us tell from the CI log whether (a) hydrate fired but the rail didn't render, (b) hydrate fired and the rail rendered but tabs are missing, or (c) hydrate never fired at all. Until now the failure just said "element not found" with no DOM context.
Per-test timeout bumped to 240s — two cold starts back-to-back can drift past the 120s suite default under xvfb contention.
0 commit comments