Skip to content

hashline edit: silently returns success when LINE#ID anchors are stale (no error on mismatch) #15424

@zitongcharliedeng

Description

@zitongcharliedeng

Bug description

When experimental.hashline_edit is enabled, making a second edit call to the same file after a first edit has already mutated it causes the tool to operate on stale LINE#ID anchors — but instead of returning an error, it returns a success response (Updated). The edit either applies to the wrong lines or is silently dropped.

This is the dangerous part: the agent receives Updated and continues, never knowing the change didn't persist correctly.

Steps to reproduce

  1. Enable experimental.hashline_edit: true in opencode.jsonc
  2. Read a file → receive LINE#ID-annotated output (snapshot A)
  3. Make an edit call using anchors from snapshot A → succeeds, file is now snapshot B
  4. Make a second edit call using anchors still from snapshot A (now stale)
  5. Tool returns Updated ✓ — but the change is wrong or lost

The expected behavior is a mismatch error, forcing a re-read before retrying.

Why this matters for agents

Agents trust tool return values. A silent success is far worse than a loud failure:

  • Agent marks the task complete and moves on
  • No retry, no re-read, no correction
  • The bug is only discovered later (e.g. a test fails, or a human reviews)

A loud ANCHOR_MISMATCH: re-read required error would force the agent to recover cleanly.

Relation to active PRs

I'm aware of #14677 ("stabilize hashline routing and anchors") and #13405. Those PRs address anchor stability — keeping anchors valid longer. This issue is a separate concern: even after those land, there will be cases where anchors are stale (e.g. external edits, tool call batching across turns). The failure mode (silent success vs. explicit error) is the distinct problem reported here.

Expected behavior

When a LINE#ID anchor cannot be matched in the current file state, the edit tool should:

  1. Return an explicit error (e.g. ANCHOR_MISMATCH: line 42#ZP not found in current file state)
  2. Include the updated LINE#IDs in the error response so the agent can retry without a full re-read
  3. Never return Updated for a no-op or misapplied edit

Environment

  • opencode 1.2.10
  • experimental.hashline_edit: true
  • Model: claude-sonnet-4-6 (anthropic)

Metadata

Metadata

Assignees

Labels

coreAnything pertaining to core functionality of the application (opencode server stuff)

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions