openclaw - 💡(How to fix) Fix edit tool should classify concurrent identical edits as noop and distinguish them from both success and failure [1 participants]

Problem

The current edit behavior does not clearly distinguish these cases when identical edits hit the same file concurrently:

1. one request actually performed the mutation
2. another identical request found the file already in the desired final state
3. the file actually failed to reach the target state

In practice, this makes it difficult to tell whether:

• the second edit really wrote anything
• the first edit already completed the desired change
• the file actually failed to reach the target state

Desired semantics

For concurrent identical edits against the same file and same target content:

• the winner should return normal success:
  Successfully replaced text in ...
• the follower should return a noop-style result:
  Edit noop: content already up to date in ...
• true mismatches / write failures should still remain errors

Order does not need to be stable.

The only important thing is that “already at desired final state” is classified separately from both success and failure.

Why this matters

This improves correctness of tool result semantics for:

• user understanding
• agent retry logic
• debugging concurrent edit behavior
• downstream workflows that need to distinguish “work was done” from “state was already correct”

Reproduction

Initial file:

alpha
beta
gamma

Send two concurrent identical edit calls.

Single replace mode

• replace beta -> BETA

Expected final file:

alpha
BETA
gamma

Expected results:

• one request: Successfully replaced text in ...
• one request: Edit noop: content already up to date in ...

Multi-edit mode

Same expectation should hold if the identical request is expressed as:

{
  "path": "...",
  "edits": [
    { "oldText": "beta", "newText": "BETA" }
  ]
}

Suggested implementation directions

I do not think this has to exactly follow any one local patch design, but I think the implementation should probably cover both of these layers:

1. Post-state classification

After an edit attempt, classify the resulting file state into:

• success
  • this request actually performed the mutation
• noop
  • desired target state is already satisfied, and this request did not need to mutate
• error
  • target state is still not satisfied / actual mismatch / write failure

This is the key semantic improvement.

2. Duplicate in-flight request handling

For identical edits on the same file, it may help to detect duplicate in-flight requests by a stable key such as:

• file path
• single replace:
  • oldText
  • newText
• multi-edit:
  • normalized edits[]

Then either:

• let the follower wait for the leader and re-check final file state
• or otherwise ensure the follower can classify itself as noop when the target state is already satisfied

This could be implemented:

• inside pi-coding-agent edit tool
• or in a higher wrapper layer if OpenClaw wants tool-specific semantics there

But conceptually, the tool should understand:

• “I wrote this”
• vs
• “someone else already made the file match what I wanted”

3. Support both input modes

This should work for:

• oldText / newText
• edits[]

It would be a mistake to only handle single replace mode, since some runtimes may emit identical logical edits via edits[].

4. Keep true failure behavior intact

If the file still does not satisfy the requested target state after waiting / rechecking, the result should still be an error.

That means:

• noop should only be returned when the requested end-state is actually satisfied
• noop should not suppress genuine mismatch / write failures

Suggested test cases

I think good regression coverage would include at least:

A. Single replace, duplicate concurrent requests

Initial file:

alpha
beta
gamma

Two concurrent identical requests:

• oldText = "beta"
• newText = "BETA"

Assert:

• exactly one success
• exactly one noop
• final file is:

alpha
BETA
gamma

B. edits[] mode, duplicate concurrent requests

Initial file:

alpha
beta
gamma

Two concurrent identical requests:

{
  "edits": [
    { "oldText": "beta", "newText": "BETA" }
  ]
}

Assert:

• exactly one success
• exactly one noop
• final file matches expected output

C. Already-up-to-date mismatch path becomes noop

Initial file already contains target content:

alpha
BETA
gamma

A request arrives with:

• oldText = "beta"
• newText = "BETA"

If the edit path would otherwise hit an exact-match mismatch, but the file already satisfies the desired final state, assert:

• result is noop
• not error

D. True failure remains error

Initial file:

alpha
gamma

Request:

• oldText = "beta"
• newText = "BETA"

Assert:

• error remains error
• no noop classification

E. Non-identical concurrent edits should not be over-collapsed

Two concurrent edits against the same file but different replacement targets should not be treated as duplicate-noop equivalents unless they truly converge to the same satisfied end-state.

This is important to avoid over-classifying unrelated concurrency as noop.

Non-goals

This issue is not asking for:

• global serialization of all edits everywhere
• strict deterministic ordering of concurrent tool results
• hiding failures behind noop

The request is specifically about more accurate result semantics when the desired target content is already satisfied by an identical concurrent edit.

Environment where this was noticed

Observed in OpenClaw 2026.3.24 with concurrent file edits in real usage.