Repository navigation
fix(memory): retry atomic writes under Windows file contention - #404
Conversation
Atomic workspace replacement used a single rename, so a temporary reader lock aborted checkpoint publication. Reuse the bounded Windows retry and preserve the original file/error when the lock persists. Real reader-handle tests cover both outcomes; 5,207 tests pass with 4 skipped and typecheck passes in the equivalent ASCII-path worktree.
- 两个用例靠 PowerShell 子进程占住目标文件，第二个靠 3800 ms 占用和 retryBusy 约 2970 ms 退避之间的余量成立，慢的 runner 上子进程起得晚就会翻红。 - 其余包了 retryBusy 的改名(state、timers、extensions、context-log)都没有按调用点 测占用。 Co-Authored-By: Claude Fable 5.2 <noreply@anthropic.com>
|
Thanks @jcs130, merged. The rename in Before merging we pushed one commit to your branch that removes The fix ships with the next release. |
A temporary Windows reader handle can make the final rename in
GitWorkspaceMemory.writeFileAtomicfail with EPERM, aborting checkpoint publication even though the temporary file was fully written.Reuse the existing bounded
retryBusyhelper for that rename. A persistent lock still raises the original error, keeps the previous checkpoint and removes the temporary file. No action or tool call is replayed.Validation: real Windows file handles reproduce the old failure and cover successful publication after release plus preservation on persistent contention. Full suite: 5,207 passed, 4 skipped; typecheck passed. Tests ran from an identical ASCII-path worktree because the existing Vite dynamic importer cannot resolve the percent-encoded non-ASCII checkout path.