Error applying diffs - "No sufficiently similar match found at start: ..."

[ryanjoachim]

Which API Provider are you using?

Anthropic

Which Model are you using?

Claude 3.5 Sonnet

What happened?

Cline is in a workflow of its own creation, editing files in sequence one by one using diffs.
It seems to struggle with updating a file that was created after the extension (or the VSCode window itself) was initialized. Cline knows its there because it creates it, but it struggles to keep track of contextual information on it. (random theory)

The general error that happens is below:

I'll now update the Editor Integration section to show how we'll integrate the existing LargeFileProcessor with the viewport-based prioritization system.

Error
Unable to apply diff to file: c:\Users\Chewy\Documents\GitHub\ryanjoachim\Roo-Cline\proposed_CurrentState.md No sufficiently similar match found at start: 17 to end: 35 (26% similar, needs 90%)

I apologize for the error. Let me try to apply the changes with more precise line numbers by first reading the current content of the file.

After this it will sometimes go on to read the file again, which allows it to successfully apply the diff.
Other times it'll go into a bit of a feedback loop until it kicks its way out, like in the image here:

Steps to reproduce

1. Ask Cline to update various parts of an existing file, using separate diffs for each change.

Relevant API REQUEST output

No response

Additional context

No response

[jeremy-returned]

To add to this, I have seen Cline now intentially creating issues as it gets the line numbers wrong when editing.

For example, you will wind up with something like:

        subscriptionId: string,
                    public async cancelSubscription(
        subscriptionId: string,
        cancelAtPeriodEnd: boolean = false
    ): Promise<Stripe.Subscription> {```

[mrubens]

@jeremy-returned @ryanjoachim can you try out 2.2.15 and let me know if you're still having issues? Thank you for the help tracking these down!

[jeremy-returned]

I spoke too soon:

Seems to be due to Cline not reading the file before writing to it.

            case 'POST':
                return await createInstallTypeHandler(event);
            case 'PUT':
                return await updateInstallTypeHandler(event);
            case 'DELETE':
                return await deleteInstallTypeHandler(event);
            case 'GET': {
                const { db, close } = await createDb();
                try {
                case 'PUT':
                    return await updateInstallTypeHandler(event);
                case 'DELETE':
                    return await deleteInstallTypeHandler(event);
                case 'GET':
                    const installTypeId = event.pathParameters?.id;
                    
                    // Get specific install type if ID is provided

[mrubens]

I spoke too soon:

Seems to be due to Cline not reading the file before writing to it.

            case 'POST':
                return await createInstallTypeHandler(event);
            case 'PUT':
                return await updateInstallTypeHandler(event);
            case 'DELETE':
                return await deleteInstallTypeHandler(event);
            case 'GET': {
                const { db, close } = await createDb();
                try {
                case 'PUT':
                    return await updateInstallTypeHandler(event);
                case 'DELETE':
                    return await deleteInstallTypeHandler(event);
                case 'GET':
                    const installTypeId = event.pathParameters?.id;
                    
                    // Get specific install type if ID is provided

Ugh. That's on 2.2.15? The export would be amazingly helpful if you can share.

[ryanjoachim]

I spoke too soon:
Seems to be due to Cline not reading the file before writing to it.

            case 'POST':
                return await createInstallTypeHandler(event);
            case 'PUT':
                return await updateInstallTypeHandler(event);
            case 'DELETE':
                return await deleteInstallTypeHandler(event);
            case 'GET': {
                const { db, close } = await createDb();
                try {
                case 'PUT':
                    return await updateInstallTypeHandler(event);
                case 'DELETE':
                    return await deleteInstallTypeHandler(event);
                case 'GET':
                    const installTypeId = event.pathParameters?.id;
                    
                    // Get specific install type if ID is provided

Ugh. That's on 2.2.15? The export would be amazingly helpful if you can share.

The behavior @jeremy-returned mentioned aligns with what we see in my screenshot, where every attempt to edit the file fails until Cline finally says "Maybe I should try reading the file again...". I wonder if my random theory - It seems to struggle with updating a file that was created **_after_** the extension (or the VSCode window itself) was initialized... - might actually have some relevance, but not necessarily in the way I was thinking.

It kind of feels more like a "short term memory loss" situation and reminded me of a known issue in Cline revolving around the file picker/add context feature, where any new files/directories added locally during an open VSCode session are not visible to the @ context file picker.
Cline is smart enough to check open files or manually check for referenced files, but the file picker remains unaware of file/directory changes until either the current folder is closed+reopened or you use a dev command like @command:workbench.action.reloadWindow. Maybe a completely separate thing, but it got me thinking -

To what extent (if at all) does Cline keep track of the state a previously read/modified file or directory, at least within each unique task? I'm getting the impression that unless a file is re-read by Cline prior to a new interaction with it, Cline isn't using the most recent structure/content to start with.
In the screenshot here you can see that:

1. Cline finally said "just reread the file already" and is then able to find the position where new content is supposed to go.
2. Cline prepares the next diff to use within the same file it just modified. It fails for the same reason.
3. Cline tries to search for "unique content" it expects to already be in the Known Limitations section, which fails.
4. Cline then seems to get confused and tries searching the directory itself for the expected ## header, ignoring file contents...which returns null/0 results.
5. Finally, Cline decides to "read the file again" and all is well.
   

[ryanjoachim]

I have the export for this conversation if anyone really wants it. It just has ~10k lines in it and didn't want someone to open thinking they were in for a quick read 😆.

I intentionally kept the conversation going to push overall token usage+fill up the webView+iFrame, and except to ask a single question (or set a task like creating a file) after each [attempt_completion] I let Cline handle itself without any instructions from me.

[mrubens]

Interesting... this could be on to something. I believe that LLMs pay less attention to content in the middle of the conversation, so that could explain why they sometimes forget the current state of the files / line numbers / etc.

Maybe there's some way to force it to re-read the file and then try applying the diff again after a failure, either with the prompt or with the response of the tool rejection 🤔