Indexer is stuck on a file, and agent changes to this file fail every time

Hi, thanks for reporting an issue with Cursor.

Before you report this, we’d appreciate if you can search this forum to see if this issue has already been reported.

If you have done so, please check this box.
on

Describe the Bug

There is one file that agent is unable to makes changes to and gets stuck in a loop where it tries to apply a change to a file, fails, then tries again, etc… and gives up eventually.

I check the indexer and it seems that it’s stuck on this same file.

I tried other files and the agent can make changes to them.

I tried deleting and recomputing the index.

Steps to Reproduce

Not sure! You would have to somehow recreate the conditions for this to happen, but they are unclear.

Expected Behavior

The agent should be able to make changes to every file and the indexer shouldn’t be getting stuck on a file.

Screenshots / Screen Recordings

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 0.44.11
VSCode Version: 1.93.1
Commit: fe574d0820377383143b2ea26aa6ae28b3425220
Date: 2025-01-03T07:59:06.361Z
Electron: 30.5.1
Chromium: 124.0.6367.243
Node.js: 20.16.0
V8: 12.4.254.20-electron.0
OS: Darwin arm64 24.0.0

Additional Information

f6258fb9-3219-49c1-9ca1-b382b9d5b008 example of request id

Does this stop you from using Cursor

Yes - Cursor is unusable

Hey, open the dev tools and check for any errors. Also, open the output panel, then click on the dropdown and select Cursor Indexing & Retrieval. Share this data here. For more information:

i get these when the agent tries to make changes to this files (doesn’t happen with other files) :

2workbench.desktop.main.js:3542 [balta] error in handleSlashEditResponseSingleDiffPure ConnectError: [invalid_argument] Error
at F.$endAiConnectTransportReportError (workbench.desktop.main.js:3755:12992)
at T.S (workbench.desktop.main.js:2950:14846)
at T.Q (workbench.desktop.main.js:2950:14612)
at T.M (workbench.desktop.main.js:2950:13645)
at T.L (workbench.desktop.main.js:2950:12480)
at b.value (workbench.desktop.main.js:2950:11175)
at $.B (workbench.desktop.main.js:470:732)
at $.fire (workbench.desktop.main.js:470:949)
at s.fire (workbench.desktop.main.js:1153:14824)
at G.onmessage (workbench.desktop.main.js:3000:8229)

Cursor indexing and retrieval output:

2025-01-10 13:02:27.169 [info] Search by sha took 14.889792000001762ms for query ""

2025-01-10 13:02:27.170 [info] Search by message took 16.877708000014536ms for query ""

2025-01-10 13:02:29.115 [info] Search by sha took 20.226083000015933ms for query ""

2025-01-10 13:02:29.116 [info] Search by message took 20.109542000020156ms for query ""

2025-01-10 13:02:29.116 [info] Search by message took 21.969458000006853ms for query ""

2025-01-10 13:02:29.117 [info] Search by sha took 20.672749999997905ms for query ""

2025-01-10 13:02:29.119 [info] Search by sha took 21.31737500001327ms for query ""

2025-01-10 13:02:29.120 [info] Search by sha took 20.018791000009514ms for query ""

2025-01-10 13:02:29.121 [info] Search by message took 23.032291999988956ms for query ""

2025-01-10 13:02:29.121 [info] Search by sha took 19.61304199998267ms for query ""

2025-01-10 13:02:29.121 [info] Search by message took 21.088958999986062ms for query ""

2025-01-10 13:02:29.121 [info] Search by message took 20.346458000014536ms for query ""

Hey, If you open a different codebase or a different project, do you still get one file stuck or is it only the one project where this happens?

What happens if you temporarily rename the file, then delete and restart the indexing? Is it successful then?

  1. Different codebase, no files getting stuck as far as I can see

  2. Renamed the file, deleted and restarted the index. Still gets stuck on it! It’s less than 1000 lines of code, Cursor is OK with other larger files. Cursor was also OK with this file up until recently

Okay, this is weird!

What about if you rename it, make a new file with the right name, and paste the same contents in?

If it’s the contents causing issues, hypothetically, both files would fail to index? Otherwise, it may just be a referencing bug with that one file!