runtime-host: WorkHub delegation can conflict with terminal root transition

[M4n5ter]

English

Problem

WorkHub delegation can drain the Runtime Host when a user delegates immediately after a target Session's answer becomes visible.

The UI remains in the routing state, Runtime Host reconnect begins, and the durable handoff fails with:

SessionMetadataConflictError: Message admission Turn conflict

This appeared consistently in three WorkHub Desktop e2e cases in CI run 33260974636, while adjacent main runs passed.

Root cause

A durable steering Message has one exact Turn/Run identity, but assignment, terminal transition, and recovery did not share one authority boundary:

• if assignment observed an active root, it committed the steering Message, released the Session admission lease, and only then projected it into the live queue; the terminal transition could make the Session idle in between;
• if the terminal transition won first, assignment correctly observed an idle root but recovery generated a different Turn/Run identity from the one already stored with the steering Message.

Both orderings could hand the Message to a root other than its durable owner. SQLite rejected that handoff, and the Runtime Host treated the authority conflict as fatal.

Required invariant

• Durable assignment and live queue ownership must be established under the same Session admission lease.
• Idle recovery of steering must use the exact Turn/Run identity already bound to the durable Message.
• A visible completed answer followed immediately by WorkHub delegation must not drain or reconnect the Host.

Resolution

PR #4185 now enforces both sides of the invariant. The focused authority tests pass, and all four affected WorkHub Desktop e2e cases pass without increasing timeouts.

中文

问题

目标 Session 的回答刚显示完成时，用户立即通过 WorkHub 委托，可能导致 Runtime Host 主动退出。

界面会一直停在路由状态，Runtime Host 开始重连，持久化 handoff 报错：

SessionMetadataConflictError: Message admission Turn conflict

该问题在 CI 运行 33260974636 的三个 WorkHub Desktop e2e 用例中稳定出现，而相邻的 main 运行正常通过。

根因

持久化 steering Message 只能属于一组确定的 Turn/Run identity，但 assignment、terminal transition 与 recovery 没有共享同一个 authority 边界：

• assignment 看到 active root 时，会先提交 steering Message，释放 Session admission lease，随后才把它投影到 live queue；terminal transition 可以在两者之间将 Session 变为 idle；
• terminal transition 先完成时，assignment 能正确看到 idle root，但 recovery 会生成一组不同于 steering Message 已存 identity 的 Turn/Run。

两种顺序都可能把 Message 交给并非其持久化 owner 的 root。SQLite 会拒绝 handoff，Runtime Host 将该 authority conflict 视为 fatal error。

必须满足的不变量

• durable assignment 与 live queue ownership 必须在同一把 Session admission lease 下建立；
• idle recovery 处理 steering 时，必须使用 durable Message 已绑定的准确 Turn/Run identity；
• 回答显示完成后立即通过 WorkHub 委托，不能导致 Host 退出或重连。

解决方案

PR #4185 已同时落实两侧不变量。聚焦 authority 测试通过，四个受影响的 WorkHub Desktop e2e 用例无需增加 timeout 即可全部通过。

[cat0825]

take

[cat0825]

Automated disclosure: the preceding claim comment was posted by OpenAI Codex at @cat0825’s direction. @cat0825 is the human contributor of record and remains responsible for reviewing and submitting the contribution.

[M4n5ter]

English

A second run of the same PR CI job failed in the same WorkHub projection area, but the exact failing set drifted from two tests to three:

• workhub-layout.spec.ts: submitted Session result did not appear
• workhub-reconstruction.spec.ts: routed prompt did not reconstruct
• workhub-reconstruction.spec.ts: linked delegation result did not reconstruct

The rest of Desktop e2e passed (87 passed, 1 skipped). The changing failure set around the same asynchronously reconstructed projection strengthens the evidence for shared state/timing instability rather than a deterministic assertion failure.

Run: https://github.com/apache/maka/actions/runs/33260974636/attempts/2

中文

同一 PR 的第二次 CI 运行仍失败在 WorkHub 投影区域，但具体失败集合从两个漂移到三个：

• workhub-layout.spec.ts：未出现已提交 Session 的结果
• workhub-reconstruction.spec.ts：路由后的提示未重建
• workhub-reconstruction.spec.ts：关联 delegation 的结果未重建

其余 Desktop e2e 均通过（87 passed，1 skipped）。同一异步重建链路上的失败集合发生漂移，进一步说明问题更可能是共享状态或时序不稳定，而不是固定断言错误。

运行记录：https://github.com/apache/maka/actions/runs/33260974636/attempts/2

[M4n5ter]

English

Thank you, @cat0825, for taking this issue.

The CI investigation for #4185 confirmed that this is a production Runtime Host authority race rather than an e2e synchronization problem. #4185 now includes the root-cause fix: durable WorkHub assignment and live queue ownership share the same Session admission lease, and idle recovery preserves the steering Message's exact Turn/Run identity.

The focused authority tests and all four affected Desktop WorkHub e2e cases pass locally without increasing timeouts. The updated PR CI is currently running. To avoid duplicate implementation work, this issue has been assigned to @M4n5ter, who owns the existing PR.

If you already have findings or an implementation in progress, please share them—we would still appreciate your review or a different perspective on the authority design.

中文

感谢 @cat0825 认领这个 issue。

对 #4185 CI 的调查确认，这不是 e2e 同步问题，而是生产环境中的 Runtime Host authority 竞态。#4185 已包含根因修复：durable WorkHub assignment 与 live queue ownership 共用同一把 Session admission lease；idle recovery 会保留 steering Message 已绑定的准确 Turn/Run identity。

聚焦的 authority 测试和四个受影响的 Desktop WorkHub e2e 用例均已在本地通过，没有增加 timeout。更新后的 PR CI 正在运行。为避免重复实现，该 issue 已分配给现有 PR 的负责人 @M4n5ter。

如果你已经有调查结论或正在进行的实现，也请继续分享；我们仍然非常欢迎你审阅当前 authority 设计，或提出不同看法。