Repository navigation
Multiple eca__edit_file calls to the same in parallel can be harmful #621
Description
To upvote this issue, give it a thumbs up. See this list for the most upvoted issues.
Please avoid AI slops, be concise, and focus on what matters for this issue.
Describe the bug
This is how agent described the problem when it encountered it:
after two eca__edit_file calls to the same file sent in one message, the file ends up
mangled (2026-09-13: run.sh got a duplicated tail with both the new and old `exec` line, plus a
partial duplicated line mid-file). Intermittent: batching sometimes works.
Cause: the second edit is applied against a stale snapshot, or the pair interleaves.
Fix: send same-file edits one per message; or prefer a single eca__write_file with the full
content, or one edit whose original spans all changes (net paren/line change of zero avoids the
editor's bracket auto-fixer reverting a change). Different files in one message are fine.
We should make the edit system smarter (or at least fail to avoid this).
Reacted by Ken Bolton and mrsch
Activity
mikemikimike commentedon Oct 25, 2026
Implemented in #668.
Same-file edits now serialize the full read/match/retry/write operation while different files remain concurrent. Regression tests cover path aliases, cancellation, failed writes, stale overlapping edits, and rollback snapshots.
clojure -M:testpassed with 1,062 tests and 6,578 assertions. All nine PR checks passed, including unit and JVM integration tests on Windows, macOS, and Linux, plus GraalVM and Nix builds.mikemikimike commentedon Oct 29, 2026
Updated PR #668 to serialize all built-in filesystem mutations on canonical paths.
edit_file,write_file, andmove_filenow avoid same-path races, while different files remain concurrent; multi-path moves acquire locks in a stable order. Added regression coverage for write-then-edit ordering. All unit, JVM integration, GraalVM, and Nix checks are passing: #668