@ file search does not work on WSL

[noahhaon]

Before submitting your bug report

• [X] I believe this is a bug. I'll try to join the Continue Discord for questions
• [X] I'm not able to find an open issue that reports the same bug
• [X] I've seen the troubleshooting guide on the Continue Docs

Relevant environment info

- OS: Windows 10
- Continue: 0.8.23
- IDE: VSCode 1.88.0
- Model: Ollama

Description

Using the @ option to "type to search" and select files does not return any files. Indexing is completed.

Interestingly if I open the continue config.json by clicking the cog icon, then config.json is the only option to select via @, even if I later close that file.

My project is a WSL project and VSCode is running on Windows. This feature used to work for me, but broke with a recent-ish update. Unfortunately, I can't pinpoint which version worked at the moment. I will see if I can rolll back and bisect it a little.

To reproduce

1. Start a new Continue session
2. Click the cog icon to open the Continue config.json
3. Type @ and get the context providers menu
4. Click Files
5. See that only .continue/config.json is visible, no other project files may be found even if their filenames are typed in.

Log output

There are no errors in the developer console that I can see, except one which I'm guessing is unrelated:


[Extension Host] Error loading color theme:  TypeError: Cannot read properties of undefined (reading 'map')
	at convertTheme2 (c:\Users\REDACTED\.vscode\extensions\continue.continue-0.8.23-win32-x64\out\extension.js:193405:25)
	at getTheme (c:\Users\REDACTED\.vscode\extensions\continue.continue-0.8.23-win32-x64\out\extension.js:194362:51)
	at ContinueGUIWebviewViewProvider.getSidebarContent (c:\Users\REDACTED\.vscode\extensions\continue.continue-0.8.23-win32-x64\out\extension.js:327261:30)
	at ContinueGUIWebviewViewProvider.resolveWebviewView (c:\Users\REDACTED\.vscode\extensions\continue.continue-0.8.23-win32-x64\out\extension.js:327216:41)
	at v.$resolveWebviewView (c:\Users\REDACTED\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:154:53474)
	at h.S (c:\Users\REDACTED\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:149:5502)
	at h.Q (c:\Users\REDACTED\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:149:5268)
	at h.M (c:\Users\REDACTED\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:149:4323)
	at h.L (c:\Users\REDACTED\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:149:3579)
	at a.value (c:\Users\REDACTED\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:149:2227)
	at s.y (c:\Users\REDACTED\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:82:659)
	at s.fire (c:\Users\REDACTED\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:82:876)
	at r.fire (c:\Users\REDACTED\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:107:14173)
	at a.value (c:\Users\REDACTED\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:175:8018)
	at s.y (c:\Users\REDACTED\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:82:659)
	at s.fire (c:\Users\REDACTED\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:82:876)
	at r.fire (c:\Users\REDACTED\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:107:14173)
	at MessagePortMain.<anonymous> (c:\Users\REDACTED\AppData\Local\Programs\Microsoft VS Code\resources\app\out\vs\workbench\api\node\extensionHostProcess.js:175:6298)
	at MessagePortMain.emit (node:events:517:28)
	at MessagePortMain._internalPort.emit (node:electron/js2c/utility_init:2:2285)

[noahhaon]

Alright, I tried several versions back to 0.7.64 and it still doesn't work, so perhaps this is a VSCode update that broke it.

I also updated to the latest version, renamed the existing dev_data and index directories under .continue and restarted VSCode, but now Indexing seems stuck at 1% and the behavior is otherwise the same. No errors in the console.

[sestinj]

@noahhaon Thanks for the report. I have a couple of questions to help figure out what's going on:

Was this something that worked previously and now seems to have regressed?

If you start typing the name of a file ("type to search") are there still no results?

[noahhaon]

Hey @sestinj -

Was this something that worked previously and now seems to have regressed?

Yes, but unfortunately I can't say when it did. It seems to have been flaky for at least a few versions. Per my prior comment, I tried rolling back versions until 0.7.64 and still saw the same behavior

If you start typing the name of a file ("type to search") are there still no results?

Correct, except in the case where I have clicked the cog icon to open up Continue's config.json then it is the only result that comes up, or will match with typing.

[noahhaon]

Note that I renamed the index and dev_data directories and restarted VSCode, and it is stuck on Indexing (1%) and has been for over an hour.

[benrosenblum]

I have the same issue with indexing stuck at 1% and the files not working for context. I'm on Windows 11, and this happens with projects both under normal windows dirs and under WSL.

[sestinj]

@benrosenblum do you also see no related error logs in the developer console? (ctrl+shift+P, "Toggle Developer Tools")? And does the same problem exist in the pre-release version (0.9.x)?

[benrosenblum]

@sestinj I see no related errors, and I've toggled to pre-release with the same issue. Weirdly, sometimes it seems to work and go green on a restart of vscode, but a short time later it will go back to the 1% re-indexing.

[sestinj]

Thanks! A note partially to myself here, but also maybe relevant for you as well, the @ file problem should be separate from the indexing problem. I'm making what I believe is a fix for the indexing problem in a new pre-release version, and I will separately take a look at the windows/WSL file problem a bit later

[noahhaon]

Thanks for all your work @sestinj - really love the extension :)

[benrosenblum]

Just want to note that if instead of using @files, if I just do @ and then start typing, the files show up in the search along with symbols.

And if I use the files context and start typing, it correctly shows just the list of files.

It's only when clicking on the files context that the popup shows "No results". I'm on pre-release now.

[benrosenblum]

Following another thread on the Discord about the @diff context provider not working under WSL (another problem I had), I tried a solution in that thread of switch the extension to be in workspace instead of UI mode:

    "remote.extensionKind": {
        "continue.continue": [
            "workspace"
        ]
    }

I had to setup config.json again since now it's hosted under the WSL env, but this seems to have resolved pretty much every issue I was having with the extension. I'll keep testing to see if this change broke anything else, but it's working well so far!

[noahhaon]

@benrosenblum this worked for me after some time with VSCode on windows and a WSL project.

Indexing is still stuck at 0% however. Using the continue pre-release version.

[sestinj]

@noahhaon do you see anything that might indicate an error in the logs?