You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@maka.apache.org by "Zestful-ss (via GitHub)" <gi...@apache.org> on 2026/09/17 09:19:36 UTC
[PR] test(desktop): cover the Plan execution lifecycle end to end [maka]
Zestful-ss opened a new pull request, #5447:
URL: https://github.com/apache/maka/pull/5447
## Summary
The Plan execution lifecycle can now be driven end to end in the real Desktop
application, and one spec covers it: Plan mode → proposal → approve → **real
progress** → Stop → **full Electron restart** → resume → completion.
Two things were missing. The lower tier already tests the Plan panel
(`src/main/__tests__/plan-mode-panel-*.test.ts`), but it fakes `window.maka` and
the DOM, so nothing showed that an interrupted execution survives an application
restart or that Stop during a live Turn settles through `RootTurnCoordinator`
into a durable interruption. And the Desktop E2E harness could not produce a Plan
at all: `FakeBackend` has no Plan support, and a main-session backend never
receives a tool list — `BackendFactoryContext.tools` is filled only for subagent
activations, where it is a permission ceiling, not the model's tools.
**The fixture invokes the production Plan tool implementations against the
composed Plan store.** The candidate composition reports the Plan authority it
composes through one optional, production-inert observer, and the test-only
backend calls `buildSubmitPlanTool` / `buildUpdatePlanTool` through it and runs
their `.impl()`, so a fixture write takes the production validation and
operation-id path. It does not go through the Runtime's tool discovery or
dispatcher, which is why the fixture reads its Turn kind from the store's active
execution rather than from a tool list. The proposal Turn submits a three-step plan; an execution Turn
records one step of progress and then holds the Turn open until the user stops
it, so the interrupt lands on durable progress; a resumed Turn completes the
remaining steps. `update_plan` is re-bound from the store's active execution on
every Turn, and each logical action keeps a stable tool-call id so a replayed
Turn takes the idempotent recovery path instead of writing twice.
**The spec asserts the cross-process boundary**, which is the only reason this
belongs in the Electron tier (the reason is recorded in `e2e-budget.json`): a
Plan execution's progress is written by a live backend Turn and Stop settles it
through the real Host turn lifecycle; the interrupted execution must then be read
back by a fresh renderer over preload/IPC after a complete Electron restart, with
its per-step statuses intact, before the resumed Turn can finish it.
<details>
<summary>中文概述</summary>
Plan 执行生命周期现在能在真实 Desktop 应用里跑通，并由一条 spec 覆盖：
进 Plan 模式 → 提交提案 → 批准 → **真实进度** → 停止 → **完整退出并重启
Electron 应用** → 恢复执行 → 完成。
原本缺两样东西。低层已经有 Plan 面板测试，但它们伪造 `window.maka` 与 DOM，
所以没有任何测试能证明「被中断的执行能在应用重启后存活」，也证明不了「运行中的
Turn 被 Stop 时会经 `RootTurnCoordinator` 落成持久的中断」。同时 Desktop E2E 的
假模型**完全无法产生 Plan**：`FakeBackend` 没有 Plan 能力，而主会话后端根本拿不到
工具表（`BackendFactoryContext.tools` 只对子代理激活填充，那是权限上限，不是模型
工具表）。
**fixture 调用生产 Plan 工具实现**：候选组合通过一个可选、对生产无影响的 observer
把组合出的 Plan 权威暴露出来，test-only 后端经它调用真实的
`buildSubmitPlanTool` / `buildUpdatePlanTool` 的 `.impl()`，因此 fixture 的写入同样
经过生产校验与 operation-id 路径（它不经过模型的工具发现与 Runtime 派发）。提案 Turn
提交三步计划；执行 Turn 记录一步真实进度后把 Turn
挂住，直到用户停止 —— 这样中断落在**已持久化的进度**上；恢复后的 Turn 完成剩余步骤。
`update_plan` 每回合都从 store 的活跃执行现绑定，且每个逻辑动作保持稳定的
tool-call id，重放时走幂等恢复路径而不是重复写入。
**spec 断言的是跨进程边界**（这也是它属于 Electron 层的唯一理由，已记入
`e2e-budget.json`）：计划进度由运行中的后端 Turn 写入、Stop 经真实 Host 回合
生命周期落定；被中断的执行必须在**完整退出并重启 Electron 应用**后（新 main
process、新 renderer、重开同一份 SQLite 状态）由全新的渲染进程经 preload/IPC
读回，且逐步状态原样保留，恢复后的 Turn 才能把它做完。
</details>
## Verification
- **RED, before the fixture capability existed** (fixture disabled, spec unchanged):
the spec fails at its first Plan assertion —
`Locator: locator('.plan-proposal-card[data-status="pending_approval"]') Error: element(s) not found` —
which also shows the Plan-mode entry path (composer ＋ menu → mode chip) already worked.
- **RED, targeted mutation on the final tree**: with only the sentinel literal in the
built test-only module renamed, so the fake model no longer submits a proposal, the
spec fails (`1 failed`); the module was then restored byte-identically
(`Get-FileHash` equal). This is the parent's independent reproduction, not the
author's.
- **GREEN, repeat runs on this branch's base** (`origin/main` at `c980b93a`):
`npx playwright test --config e2e/playwright.config.ts e2e/plan-execution-lifecycle.spec.ts --repeat-each=5 --workers=1`
→ `5 passed (1.4m)` (18.9s, 16.0s, 16.8s, 15.2s, 15.6s); raw log in
`_local-evidence/pr-desktop-plan-e2e/verify-plan-repeat5.log`, preceded by single
green runs of 17.1s and 14.1s.
- **One environment failure, not in this spec's legs.** An earlier `--repeat-each=3`
batch was 2 passed / 1 failed, and the failure was
`electronApplication.firstWindow: Timeout 30000ms exceeded while waiting for event "window"`
in `withE2eWindow` — fixture *setup*, before any Plan assertion. `app.firstWindow()`
uses Playwright's fixed 30 s default, independent of this config's 60 s test timeout,
so that run's app simply took longer than 30 s to open its first window. In the same
session the untouched, pre-existing `session-local-recovery.spec.ts` was also
2 passed / 1 failed, with the known Windows teardown flake
(`EBUSY: resource busy or locked, unlink …\DIPS`), so this is fixture-machine
flakiness rather than a property of the new spec.
- **On a failed `.last-run.json` a reviewer may find**: it belongs to a run invoked
*without* `--config` (Playwright defaults: 30 s timeout, `outputDir`
`apps/desktop/test-results`), where the restart leg's relaunch hit the dev-profile
single-instance dialog (`Maka Dev 已在运行`) because the 30 s test timeout had already
begun tearing the first instance down. The config-based record — the one `npm run e2e`
writes, `apps/desktop/e2e/test-results/.last-run.json` — is `passed`. Electron specs
must be invoked with `--config e2e/playwright.config.ts`.
- `npm run check:e2e-budget` → `E2E budget holds: 38 tests in 22 files.` (was 37/21)
- `node --test packages/runtime-host/dist/__tests__/desktop-e2e-execution.test.js` → 2/2
- `npm run check:stale` → `dist is fresh.`; `npm run lint`, `npm run format:check` → clean;
`npm run typecheck` → no `error TS`.
The full E2E suite was not run (22 files, many minutes). Two neighbouring specs were
re-run as a fixture regression check for the shared fixture code this PR touches:
`streaming-remount.spec.ts` and `expected-failure-feedback.spec.ts` → 5 passed, plus
the same teardown-only `EBUSY …\DIPS` failure documented above.
## Review focus
- **The one production change**: an optional `observePlanStore` field on
`ExecutionRuntimeHostCompositionDependencies` and one call site immediately after
the composed Plan authority. Unset means no extra work and no new error path; the
Desktop E2E composition is its only consumer, in the same spirit as a candidate
entrypoint that selects a test-only entry module.
- **A deliberate deviation from an obvious assertion**: the final leg does not assert a
rendered `3/3 步`. `PlanExecutionPanel` renders `active ?? lastInterrupted`, and the
completion event clears `activeExecutionId` in the same store transition that
records the last step, so the panel — its count included — unmounts in that commit.
The leg asserts panel absence plus the terminal projection
(`{ activeExecutionId: null, status: 'completed', completed: 3, total: 3 }`) through
the same `getPlanState` preload read the panel uses, rather than inventing a DOM
state the product never renders.
- **A trade-off to weigh**: the spec restates the sentinel literal
(`'__e2e_plan_proposal__'`) instead of importing it, because that test-only module
has no package subpath and adding one changes the release-manifest policy test's
expected omission list. A divergence fails the spec at its first assertion rather
than passing quietly; happy to add the subpath if you prefer the import.
## AI use
Select exactly one:
- [ ] No generative tool made a substantive contribution
- [x] Generative tooling made a substantive contribution
Tool(s) and scope: ChatGPT planned the work and reviewed it against the code;
DeepSeek Harness (DSH) implemented the fixture and the spec, including a delegated DSH
subagent for the iteration, and ran every check quoted above. The human contributor
directed the work and reviewed the change. Both commits carry a
`Generated-by: DeepSeek Harness` trailer.
## Checklist
- [x] Tests cover the change and fail without it
- [x] Lint, format, typecheck, the E2E budget gate and the affected suites pass locally
Does this PR entail a change in behavior?
- [ ] Yes
- [x] No production runtime behavior change — the change adds one optional test-only
composition observer that production callers leave unset.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] test(desktop): cover the Plan execution lifecycle end to end [maka]
Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on PR #5447:
URL: https://github.com/apache/maka/pull/5447#issuecomment-6379486679
<!-- maka-lifecycle:stale-close -->
This pull request has been closed because it received no new commits during the 7-day grace period. This is not a judgement on the merit of the change; it only keeps the review queue aligned with work that is actively in flight.
The branch and review history are preserved. Push a new commit and reopen the pull request whenever the work is ready to continue.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] test(desktop): cover the Plan execution lifecycle end to end [maka]
Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] closed pull request #5447: test(desktop): cover the Plan execution lifecycle end to end
URL: https://github.com/apache/maka/pull/5447
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org
Re: [PR] test(desktop): cover the Plan execution lifecycle end to end [maka]
Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on PR #5447:
URL: https://github.com/apache/maka/pull/5447#issuecomment-6229220126
<!-- maka-lifecycle:stale-warning -->
This pull request has had no new commits for 30 days and has been marked stale. It will be closed in 7 days unless a new commit is pushed.
Comments do not reset this timer: only a new commit does. If the pull request is intentionally long-lived, a maintainer can apply the `pinned` label.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@maka.apache.org
For additional commands, e-mail: commits-help@maka.apache.org