What happened
apps/desktop/e2e/workhub-layout.spec.ts intermittently times out while waiting for .workhub-result.
The test currently treats the following assertion as proof that WorkHub is ready:
await expect(page.getByRole('main', { name: 'WorkHub' })).toBeVisible();
However, both WorkHubCoordinationStatus and the ready WorkHubSurface render a <main aria-label="WorkHub"> and a composer. The assertion can therefore pass while the Coordination Session is still resolving.
If the test fills the composer and presses Enter during that state, submission is correctly blocked by sendBlocked. The resolving component is then replaced by the ready surface, but no request was accepted, so .workhub-result never appears.
Expected behavior: the E2E should wait until the real WorkHub conversation surface can accept input before submitting, then continue to verify that the submitted Session result is rendered without overlapping its target metadata.
How to reproduce
-
Build the repository from the root:
-
Repeatedly run the focused E2E:
cd apps/desktop
npx playwright test \
--config=e2e/playwright.config.ts \
e2e/workhub-layout.spec.ts \
--repeat-each=10 \
--workers=1
-
Observe an intermittent timeout at:
await expect(page.locator('.workhub-result')).toBeVisible();
Observed during diagnosis:
The failure is also reproducible without the proxy-password changes from PR #3704.
Environment
Logs, screenshots, or additional context
Investigation indicates this is a test-readiness race rather than a WorkHub routing or execution failure.
Relevant code:
apps/desktop/e2e/workhub-layout.spec.ts
apps/desktop/src/renderer/workhub-surface.tsx
apps/desktop/src/renderer/app-shell.tsx
Implementation constraints:
- Preserve the WorkHub architecture defined in
docs/workhub-domain-language.md: the active Runtime Host's stable Coordination Session remains the authority for the WorkHub conversation.
- Keep submission blocked while the Coordination Session is resolving.
- Synchronize the E2E with a semantic ready state that distinguishes
WorkHubSurface from WorkHubCoordinationStatus.
- Do not use a fixed delay or retry-only workaround.
- Do not weaken or remove the
.workhub-result and layout assertions.
- Do not introduce a fallback write path, duplicate transcript state, or an ordinary-Session submission before coordination readiness.
Acceptance criteria:
- The test submits only after the ready WorkHub surface can accept input.
- The existing result and non-overlap assertions remain intact.
- The focused test passes for at least 20 repeated executions.
- The Coordination startup failure/recovery E2E continues to pass.
Related but not duplicate:
What happened
apps/desktop/e2e/workhub-layout.spec.tsintermittently times out while waiting for.workhub-result.The test currently treats the following assertion as proof that WorkHub is ready:
However, both
WorkHubCoordinationStatusand the readyWorkHubSurfacerender a<main aria-label="WorkHub">and a composer. The assertion can therefore pass while the Coordination Session is still resolving.If the test fills the composer and presses Enter during that state, submission is correctly blocked by
sendBlocked. The resolving component is then replaced by the ready surface, but no request was accepted, so.workhub-resultnever appears.Expected behavior: the E2E should wait until the real WorkHub conversation surface can accept input before submitting, then continue to verify that the submitted Session result is rendered without overlapping its target metadata.
How to reproduce
Build the repository from the root:
Repeatedly run the focused E2E:
Observe an intermittent timeout at:
Observed during diagnosis:
The failure is also reproducible without the proxy-password changes from PR #3704.
Environment
6762085e2(upstream/main); also observed on the PR fix(desktop): make proxy credential updates explicit and Host-owned #3704 merge resultarm64)Logs, screenshots, or additional context
Investigation indicates this is a test-readiness race rather than a WorkHub routing or execution failure.
Relevant code:
apps/desktop/e2e/workhub-layout.spec.tsapps/desktop/src/renderer/workhub-surface.tsxapps/desktop/src/renderer/app-shell.tsxImplementation constraints:
docs/workhub-domain-language.md: the active Runtime Host's stable Coordination Session remains the authority for the WorkHub conversation.WorkHubSurfacefromWorkHubCoordinationStatus..workhub-resultand layout assertions.Acceptance criteria:
Related but not duplicate: