test(desktop): WorkHub reconstruction E2E fails at unstable projection checkpoints

[Astro-Han]

What happened

The Desktop E2E suite repeatedly fails in the WorkHub layout/reconstruction specs under GitHub Actions, with the failing checkpoint moving between runs.

This first surfaced while validating PR #4203, whose only changed file is packages/ui/src/prompt-anchor-rail.tsx and whose WorkHub surface does not mount Prompt Anchor Rail. It then reproduced on two consecutive main pushes with the same WorkHub tests:

• PR perf(ui): scope prompt rail observation to mounted turns #4203, first run: workhub-layout.spec.ts and both workhub-reconstruction.spec.ts tests failed because result/projection elements did not appear.
• PR perf(ui): scope prompt rail observation to mounted turns #4203, failed-job rerun: the first reconstruction test reached the submitted button, but the button was detached during Playwright's click; the correction test later timed out waiting for its WorkHub error projection.
• main at 8aed381eab3aa429d786a1aafc137fa7163d4e34: the same three WorkHub tests failed at result/submission/correction checkpoints.
• main at 798026359472b6ddb7623232d4a20cf70af27e47: the same three WorkHub tests failed again; one run observed the correction composer remaining disabled.

Expected behavior: once a WorkHub submission or correction has settled at its authoritative coordination boundary, the corresponding projected turn/result should remain stable long enough for navigation and layout contracts to be exercised. The E2E suite should not fail unrelated pull requests or consecutive main pushes at different transient checkpoints.

This is related to, but distinct from, #3762. That issue covered automatic Session-title timing and was fixed by explicitly renaming the source Session. The current failures happen after WorkHub startup and vary across submitted-result, projected-turn, navigation, and correction states rather than reporting New Chat.

How to reproduce

The failure is timing-dependent. The strongest current reproduction is the full Linux/Xvfb CI path, but the focused specs can be sampled repeatedly:

1. Check out current main.

2. Install dependencies and build the production Desktop app.

3. Run the two WorkHub specs repeatedly with one worker:

   cd apps/desktop
   npx playwright test \
     --config e2e/playwright.config.ts \
     e2e/workhub-layout.spec.ts \
     e2e/workhub-reconstruction.spec.ts \
     --repeat-each=10 \
     --workers=1 \
     --reporter=line

4. On Linux, use the same Xvfb composition as CI:

   xvfb-run -a npm exec -w @maka/desktop -- playwright test \
     --config e2e/playwright.config.ts \
     e2e/workhub-layout.spec.ts \
     e2e/workhub-reconstruction.spec.ts \
     --repeat-each=10 \
     --workers=1

5. Observe that failures can move between:

   • .workhub-result or .workhub-submitted never becoming visible;
   • a submitted-session button being replaced/detached while Playwright clicks it;
   • the reconstructed projected turn not appearing after navigating away and back;
   • the correction composer remaining disabled or the expected .workhub-error not appearing.

Environment

• Repository: apache/maka
• Surface: Desktop Electron E2E / WorkHub
• CI OS: GitHub-hosted Linux runner with Xvfb
• Node.js: 24
• Electron: 43.4.1
• Playwright: repository lockfile version
• Reproduced on main:
  • 8aed381eab3aa429d786a1aafc137fa7163d4e34
  • 798026359472b6ddb7623232d4a20cf70af27e47
• Also reproduced twice on PR perf(ui): scope prompt rail observation to mounted turns #4203 head 6476be8e6d388613225b892902c314b6cec90b0e

Logs, screenshots, or additional context

Observed runs:

• PR perf(ui): scope prompt rail observation to mounted turns #4203, including the failed-job rerun: https://github.com/apache/maka/actions/runs/33264030950
• main at 8aed381e: https://github.com/apache/maka/actions/runs/33264297263
• main at 798026359: https://github.com/apache/maka/actions/runs/33265089579

The evidence establishes a WorkHub coordination/projection stability problem, but does not yet isolate whether the owner defect is in coordination lifecycle settlement, renderer subscription/reconstruction, or the E2E readiness boundary. The changing failure point argues against fixing this with a larger timeout or generic Playwright retries.

Suggested investigation direction:

1. Trace one WorkHub action from the coordination Session's authoritative persisted/live state through startWorkHubCoordinationLifecycle and createDesktopWorkHubCoordinationPort into the projected turn.
2. Determine why an already located submitted button can be replaced while the same logical action is settling, and why the next projected/correction state can remain absent or disabled.
3. If production state is correct and only the test checkpoint is transient, wait on the existing authoritative readiness signal before asserting layout/navigation. If the projected state itself regresses, fix it once at the coordination owner and retain the E2E as the regression contract.
4. Do not add suite retries, fixed sleeps, a parallel WorkHub store, or a second lifecycle/scheduler to make the fixture pass.

Why it matters: the required CI / test check is red on unrelated PRs and on consecutive main pushes, while 87-88 of 91 Desktop E2E tests pass. Re-running can move the failure but does not reliably clear it.

---

Filed with AI assistance (OpenAI Codex): the agent compared the exact PR attempts, consecutive main runs, changed-file reachability, the current WorkHub specs, and the earlier #3762 fix before filing.

[Astro-Han]

I'm working on this.