Cursor retaining old folder and file references after deleted, even after reindexing

Bug Report
1

I’ve been running a fantastic cursor composer prompt using a notepad and folder reference for the last 3 weeks. Today it began to hang on “Generating…”. Checking the activity log online I saw no requests were ever made to o1-preview. I opened dev tools and noticed these two errors:

Error checking file existence: Error: Unable to resolve filesystem provider with relative file path 'cursor.aisettings:cursor/aisettings'

Error checking file existence: Error: Unable to resolve filesystem provider with relative file path 'webview-panel:webview-panel/webview-d10f7007-8948-4391-b11d-b900fb955769'

And checking renderer.log I found this:

[error] Unable to resolve nonexistent file 'c:\****\projects\ai\output\2024-09-19_to_2024-09-25': Error: Unable to resolve nonexistent file

Other useful context:

  • This project includes a symlinked directory (in gitbash)
  • I delete and recreate the symlink every time I open this cursor project
  • I delete and recreate the codebase index every time I open this cursor project

What happened

From renderer.log I could see Cursor was referencing the wrong folder, one that no longer exists. After a few tests I noticed Cursor still autocompletes files and folders in chat/composer (@file, @folder) even though they no longer exist, even after I have deleted and recreated the codebase index.

So, in my prompt I selected the wrong folder when using an @folder reference, and that caused Cursor to hang indefinitely without errors in the UI.

Problem 1: Old references are not being removed from the index

The first issue is that these old files and folders aren’t getting removed from the codebase index. Even with an explicit deletion, and recreation, of the index. This results in erroneous recommendations in chat and composer.

Problem 2: No errors in the UI, no canceled submission

There were 2 error locations that identified at the problem, neither of which canceled the composer submission. As a result, I sat there for 5 minutes waiting on the “slow” o1-preview, expecting it to return eventually, when actually, the prompt was never sent.

A better solution here would be to cancel the prompt submission at the very least so users know not to wait for it. If something fails, the UI should not pretend it’s still working.

Solution

Good luck team! Thanks for an incredible product, I look forward to updates and fixes :slight_smile:

2

if you face long path file problem is further just try out long path tool for easily fix the problem