Skip to content

Keep delegation recovery moving through Windows file sharing conflicts - #8321

Open
loopx-agent wants to merge 1 commit into
mainfrom
codex/windows-delegation-record-sharing-20261108
Open

loopx-agent wants to merge 1 commit into
mainfrom
codex/windows-delegation-record-sharing-20261108

Conversation

@loopx-agent

Copy link
Copy Markdown
Collaborator

A concurrent status reader on Windows can deny replacement of a delegation record. A transient failure after revalidation can leave the original operation at turn_returned with no active worker. The frozen 2.3.0 source hit that symptom in the SQLite Windows recovery case. Failing job

Use the shared atomic writer to retry Windows replacement for up to 500 ms within the existing write fence. The writer preserves the serialized bytes and propagates persistent errors. The retry does not rerun validation, the Host, or settlement.

A one-time replacement denial stranded the operation on the base for both File and SQLite. The same recovery path reached accepted on this branch with the original Turn key and one Host invocation. The injected test ran on macOS. The affected recovery and process cleanup checks passed locally (18 passed, 9 skipped). A Windows regression holds a real handle that denies replacement through the first attempt. Its native CI result is pending. Windows sharing semantics

Signed-off-by: LoopX Agent <337587101+loopx-agent@users.noreply.github.com>

@loopx-agent loopx-agent left a comment

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Reviewer: model_agent, gpt-6.1-sol, OpenAI, runtime_reported, reasoning_effort=max

Approval conclusion (author-owned PR; GitHub blocks formal self-approval)

动机 / Motivation

Windows 上的委派操作方需要在原 Turn 已完成时取得稳定的接受记录,并能安全恢复持续失败。 在实际委派的 accepted 原子替换处注入瞬时或持续拒绝,并以同一 operation 检查恢复。 短暂拒绝同轮恢复;持续拒绝保留原记录并按同一操作恢复。 覆盖复用 inbox._write 的现有协作 JSON 写入(包括委派、收件箱、同伴记录和 Stop)。本次没有修改 canonical authority 存储、Turn 结算或锁协议。 本机在 macOS 只注入 Windows 错误;新增 Windows 真句柄回归及 2.3.0 Windows SQLite 发布运行尚未独立验证。

改动思路 / Approach

共享 writer 仅接收原字节、私有目录 mode 和重试窗口。typed accepted 仍在原状态检查后写入,Stop/权限没有新的旁路。 让既有原子写入 owner 处理同目录临时文件、fsync、替换和清理,500 ms 只用于 Windows 的指定替换错误;业务调用及锁顺序留在原 owner。 覆盖复用 inbox._write 的现有协作 JSON 写入(包括委派、收件箱、同伴记录和 Stop)。本次没有修改 canonical authority 存储、Turn 结算或锁协议。

具体改动 / Changes

基线为 8a4d4f9dab17b01d6fe3546936155b4d718fc20d。现有契约要求运输层保留原 Turn、Host 归属和一次性结算。 基线规范

  • 短暂拒绝。 File 和 SQLite 的短暂拒绝对照中,基线只尝试一次并留下 turn_returned;候选在原 dispatch 锁内第二次成功(约 53–54 ms),原操作直接成为 accepted。
  • 持续错误。 持续拒绝两组均约 0.50 s 后抛出 WinError 5,旧记录字节未变,临时文件删除且锁可重新取得。解除拒绝后以同一 operation/Turn 继续;Host 仍一次、原结算 journal 及单次 debit、原回复均未变。POSIX 拒绝和非 5 的 WinError 均只尝试一次。
  • 原生资格。 本机在 macOS 只注入 Windows 错误;新增 Windows 真句柄回归及 2.3.0 Windows SQLite 发布运行尚未独立验证。

关键代码讲解

协作 writer → 共享替换。原委派在 终态提交 前完成结算,锁和下一步仍由该调用方持有。

对主干的风险 / Risks

重试窗口适用于同一协作 writer 的 Windows 发布,包括 Stop 或 peer 记录;在现有锁内的延迟仅在相应错误出现时增加。持续拒绝退出后可再次取锁。Windows 真机是否重现相同竞争需要发布验证。

基线和候选各 6 项独立故障对照通过;候选增加了真实 Windows reader handle 回归。 Quick premerge 的 6 项直接检查和 2 项选中检查通过。 DCO 与最新主干合并树通过。 实测使用原有 dispatch 锁;每次候选重试时第二个锁尝试均不能取得,持续拒绝退出后可重新取得。 远端 CI 未取样。

我的整体评价 / Verdict

代码评审批准。共享写入修复范围合适,注入验证保留原 Turn、一次 Host、一次结算和原回复;本结论不代替 Windows 发布验证。 本机在 macOS 只注入 Windows 错误;新增 Windows 真句柄回归及 2.3.0 Windows SQLite 发布运行尚未独立验证。

English verdict: APPROVE. Approve the bounded atomic replacement retry. Matched File/SQLite probes preserved the original Turn, one Host invocation and one settlement; verify the real Windows handle and SQLite release path before release.

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant