anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-23 10:45:33 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

Concurrency bug: Polaris edit session blocked by self-induced file change #2692

New Issue
Closed
opened 2026-02-16 17:36:51 -05:00 by yindo · 1 comment
yindo commented 2026-02-16 17:36:51 -05:00
Owner
Copy Link
Copy Source

Originally created by @riatzukiza on GitHub (Nov 8, 2025).

Summary

When Polaris alpha runs concurrent edits and uses the Read/Edit tools against the newly introduced prompt file (packages/opencode/src/session/prompt/polaris.txt), OpenCode incorrectly treats its own prior edits in the same session as an external modification. This triggers the "file has been modified since it was last read" protection and causes legitimate concurrent edits from the same agent/session to be blocked.

Details

  • Environment: opencode repo, OpenCode v1.0.45, latest dev (after addition of packages/opencode/src/session/prompt/polaris.txt)
  • Actor: Polaris alpha (OpenCode agent) performing concurrent edits via the Edit tool
  • Observed behavior:
    • Polaris reads a file.
    • Polaris (or its sub-operations) edits the same file as part of the session.
    • Subsequent parallel edits in the same logical session are rejected with messages like:
      • "File ... has been modified since it was last read. Please read the file again before modifying it."
    • This appears even though the only intervening modifications were made by Polaris itself as part of the same workflow.
  • This effectively creates a race condition / false-positive concurrency conflict for self-induced changes when multiple edits are in flight.

Expected behavior

  • The modification detection should distinguish between:
    • Conflicts caused by external writers / other sessions (should be blocked), and
    • Changes made by the same Polaris/OpenCode session or atomic multi-edit operation (should be allowed or auto-rebased).
  • Concurrent edits initiated by the same logical session/agent to the same file should not be blocked solely because an earlier step in that session updated the file.

Impact

  • Breaks multi-step and concurrent edit workflows driven by Polaris/OpenCode.
  • Forces unnecessary re-reads and manual intervention, and in some cases makes automated refactors/large changes impossible.

Possible direction

  • Track per-session version IDs or edit tokens so that edits can be validated against a session-aware version, not only the raw mtime/hash.
  • Allow batched/atomic multi-edit operations where multiple edits share the same read snapshot.
  • Ensure that edits to internal prompt/config files (e.g. packages/opencode/src/session/prompt/polaris.txt) do not spuriously poison subsequent edits from the same session.
Image
Originally created by @riatzukiza on GitHub (Nov 8, 2025). ### Summary When Polaris alpha runs concurrent edits and uses the Read/Edit tools against the newly introduced prompt file (packages/opencode/src/session/prompt/polaris.txt), OpenCode incorrectly treats its own prior edits in the same session as an external modification. This triggers the "file has been modified since it was last read" protection and causes legitimate concurrent edits from the same agent/session to be blocked. ### Details - Environment: opencode repo, OpenCode v1.0.45, latest dev (after addition of packages/opencode/src/session/prompt/polaris.txt) - Actor: Polaris alpha (OpenCode agent) performing concurrent edits via the Edit tool - Observed behavior: - Polaris reads a file. - Polaris (or its sub-operations) edits the same file as part of the session. - Subsequent parallel edits in the same logical session are rejected with messages like: - "File ... has been modified since it was last read. Please read the file again before modifying it." - This appears even though the only intervening modifications were made by Polaris itself as part of the same workflow. - This effectively creates a race condition / false-positive concurrency conflict for self-induced changes when multiple edits are in flight. ### Expected behavior - The modification detection should distinguish between: - Conflicts caused by external writers / other sessions (should be blocked), and - Changes made by the same Polaris/OpenCode session or atomic multi-edit operation (should be allowed or auto-rebased). - Concurrent edits initiated by the same logical session/agent to the same file should not be blocked solely because an earlier step in that session updated the file. ### Impact - Breaks multi-step and concurrent edit workflows driven by Polaris/OpenCode. - Forces unnecessary re-reads and manual intervention, and in some cases makes automated refactors/large changes impossible. ### Possible direction - Track per-session version IDs or edit tokens so that edits can be validated against a session-aware version, not only the raw mtime/hash. - Allow batched/atomic multi-edit operations where multiple edits share the same read snapshot. - Ensure that edits to internal prompt/config files (e.g. packages/opencode/src/session/prompt/polaris.txt) do not spuriously poison subsequent edits from the same session. <img width="1989" height="1149" alt="Image" src="https://github.com/user-attachments/assets/c2337162-6077-4986-834e-ea37d2c5c362" />
yindo added the opentui label 2026-02-16 17:36:51 -05:00
yindo closed this issue 2026-02-16 17:36:51 -05:00
yindo commented 2026-02-16 17:36:51 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Nov 8, 2025):

This issue might be a duplicate of existing issues. Please check:

  • #2882: Describes the same "Please read the file again before modifying it" error when doing parallel edit tool calls on the same file
  • #3856: Reports race condition when applying changes immediately after each other on the same file
  • #3681: Feature request to use hash comparison as fallback for file modification detection, which would solve the underlying timestamp-based detection issue

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Nov 8, 2025): This issue might be a duplicate of existing issues. Please check: - #2882: Describes the same "Please read the file again before modifying it" error when doing parallel edit tool calls on the same file - #3856: Reports race condition when applying changes immediately after each other on the same file - #3681: Feature request to use hash comparison as fallback for file modification detection, which would solve the underlying timestamp-based detection issue Feel free to ignore if none of these address your specific case.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label opentui
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#2692
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?