Open alexciarlillo opened 3 weeks ago
Does the error happen on every js file opened or only files from the project mentioned? Currently I have no idea how this could happen, but if the error didn't occur with typescript-language-server
, it is very likely the problem is from here. Could you provide a tsserver log for this error by command open_tsserver_log
to help troubleshooting? The log will contain the source files it recognized contained in the project and we can see if the reported missing source file is in there.
Do I need verbose logging on for this? The project is quite large and the verbose file is huge and also appears to have some of the file contents. I want to ensure I am not potentially leaking anything from sharing these logs.
Do I need verbose logging on for this?
Yes, verbose logging is needed.
I want to ensure I am not potentially leaking anything from sharing these logs.
I see. Does the error only happen on the specific project or any random js files? You can just try to create another test project and open a js file in it to reproduce the error and provide the log from it, which does not contain any sensitive information.
It does appear so far to be limited to only this project and it does not seem to happen on every file. I am starting to think it is possibly our jsconfig files which are to blame here. We have code that generates these for us because we use some custom named module importing stuff. I just never had an issue with this previously but I am thinking it could just as likely be a newer tsserver / typescript version rather than vtsls itself. I had not really taken updates to my neovim config for a while so a lot of things changed.
I am going to go ahead and close this out and will try troubleshooting through the logs myself as time permits. I don't want to clutter things up with issues which are likely specific to my weird gigantic legacy project 🤣 If I do find anything that definitively points to vtsls I'll let you know.
Thanks!
For what it's worth I'm noticing this a lot on monorepo projects.
@helgardferreira Did you see the error on file open and the reported missing file is the current file? If you could provide client lsp log (with file content removed) or reproduction for it, we can track it in another issue.
I'm seeing this a lot, too. I can't currently correlate when or how this starts happening but here's what I know:
[WARN][2024-06-28 11:31:47] ...lsp/handlers.lua:135 "The language server eslint triggers a registerCapability handler for workspace/didChangeWorkspaceFolders despite dynamicRegistration set to false. Report upstream, this warning is harmless"
[WARN][2024-06-28 11:32:36] ...m/lsp/client.lua:1023 "server_request: no handler found for" "workspace/diagnostic/refresh"
[ERROR][2024-06-28 11:32:36] ...lsp/handlers.lua:623 "Failed to refresh diagnostics"
[ERROR][2024-06-28 13:19:10] .../vim/lsp/rpc.lua:770 "rpc" "/Users/max/.local/share/nvim/mason/bin/vtsls" "stderr" "node:internal/process/promises:289\n triggerUncaughtException(err, true /* fromPromise */);\n ^\n\n_TypeScriptServerError: <semantic> TypeScript Server Error (5.4.5)\nCould not find source file: /path/to/file
---snip---
@gegenschall Thanks for your information. But unfortunately the logs before the error are from eslint and not related here... It would be really helpful if log level could be set to debug to show more context about the error, like if the file is opened before and the request triggering the error.
There are also some config options you can try to play with (also for anyone encountering the same issue):
typescript.tsserver.maxTsServerMemory
: This defaults to 3GB, maybe needs to be adjusted to fit the large monorepo.typescript.tsserver.watchOptions
: This controls how the tsserver tracks file, see the schema for it where different watching strategies are available for testing.vtsls.autoUseWorkspaceTsdk
: Toggle this to see if the problem is related to the version of typescript used.That's awesome, @yioneko. I'll keep my config as is and switch on debug logging in the hope of triggering those errors and then fiddle around with the parameters after.
I believe it happens more often if files are actually moved and/or there's large amounts of errors in those files. LspRestart
doesn't always help, I have to close and reopen nvim usually.
Will report back.
I am also experiencing the same error, but it only happens on new files and open that file really quick after create. ( Also only if the project is huge which means there's lots of types declaration ) E.g. if I open that file few seconds after creating it the vtsls server will not crash.
LspRestart doesn't always help, I have to close and reopen nvim usually.
The server crashed ( at least in my case ) so you need to LspStart vtsls
Finally have some idea how this could happen. Does the error usually triggered on server starting?
@RayGuo-ergou Could you test with the following key mapping (pressing <A-i>
will delete and create the file at the maximum possible speed):
vim.keymap.set("n", "<A-i>", function()
local fname = "fast_create.ts"
local cname = A.nvim_buf_get_name(A.nvim_get_current_buf())
if vim.fn.fnamemodify(cname, ":t") == fname then
vim.cmd.bdelete({ bang = true })
os.remove(cname)
else
local file = io.open(fname, "w")
file:write("")
file:close()
vim.cmd.edit({ args = { fname } })
end
end, {})
If this is 100% reproducible for you, then the problem would be much easier to work on. And if possible, please post the full error stack for tracing the original request.
Hi @yioneko Thanks for that, I have tried that and found the issue would not happen on ts
files but vue
files. 🤔 I am not sure now is it vue plugin's issue or vtsls, btw tsserver
also have issue with new vue
file but in my case tsserver
will not crash it just not working for the new file but vtsls
does crash.
Here's the crash log
[ERROR][2024-07-01 22:35:46] .../vim/lsp/rpc.lua:772 "rpc" "/home/raydev/.local/share/nvim/mason/bin/vtsls" "stderr" "node:internal/process/promises:391
triggerUncaughtException(err, true /* fromPromise */);
^
\n_TypeScriptServerError:
@RayGuo-ergou Thanks, it is much clearer now. Did you see something like A non-recoverable error occurred while executing tsserver command: encodedSemanticClassifications-full
before the crashing log? It seems that the crashing is due to the request of semantic tokens. Does it still crash if you set server_capabilities.textDocument.semanticTokens = nil
in nvim?
Sometimes I will get this error message about semantic token
( not always and not in lsp log).
Error 13:35:58 msg_show.lua_error Error executing vim.schedule lua callback: ...local/share/nvim/runtime/lua/vim/lsp/semantic_tokens.lua:309: ...local/share/nvim/runtime/lua/vim/lsp/semantic_tokens.lua:102: Invalid buffer id: 13
stack traceback:
[builtin#36]: at 0x5652345912a0
...local/share/nvim/runtime/lua/vim/lsp/semantic_tokens.lua:309: in function 'handler'
/usr/local/share/nvim/runtime/lua/vim/lsp/client.lua:687: in function ''
vim/_editor.lua: in function <vim/_editor.lua:0>
Below is messages before the log above. Which I don't think it's related.
I have added this to my config but it still happening
mason_lspconfig.setup({
handlers = {
function(server_name)
local server = servers[server_name] or {}
server.capabilities = vim.tbl_deep_extend('force', {}, capabilities, server.capabilities or {})
+ if server_name == 'vtsls' then
+ server.capabilities.textDocument.semanticTokens = nil
+ end
print(vim.inspect(server.capabilities))
require('lspconfig')[server_name].setup(server)
end,
},
})
The error message are the same
[ERROR][2024-07-02 13:48:01] .../vim/lsp/rpc.lua:772 "rpc" "/home/raydev/.local/share/nvim/mason/bin/vtsls" "stderr" "node:internal/process/promises:391
triggerUncaughtException(err, true /* fromPromise */);
^
\n_TypeScriptServerError:
It still shows error for getEncodedSemanticClassifications
wondering if that used by vue languager server plugin? 🤔
Sorry, it is my bad. We should use server_capabilities.semanticTokensProvider = nil
to disable semantic tokens on nvim client.
The vim.schedule
error is an issue on nvim side and I could see that too. It is caused by not checking buffer validity in async callback.
If you didn't see the message before the crashing log, then I think it is not the semantic tokens that causing the crash. Could you see more detailed logs by vim.lsp.set_log_level("DEBUG")
before crashing?
Sorry, it is my bad. We should use server_capabilities.semanticTokensProvider = nil to disable semantic tokens on nvim client.
After this I got these errors ( by searching with [ERROR]
. ). It seems it's caused by vue-plugin. 🤔
```
[ERROR][2024-07-02 15:08:41] ...lsp/handlers.lua:624 "[Vue Named Pipe Client] Timeout"
```
```
[ERROR][2024-07-02 15:08:41] ...lsp/handlers.lua:624 "[Vue Named Pipe Client] Timeout"
```
[ERROR][2024-07-02 15:08:59] .../vim/lsp/rpc.lua:772 "rpc" "/home/raydev/.local/share/nvim/mason/bin/vue-language-server" "stderr" "/home/raydev/.local/share/nvim/mason/packages/vue-language-server/node_modules/@vue/language-server/node_modules/@vue/language-service/lib/plugins/vue-sfc.js:184\n label: base.label + ' lang=\"ts\"',\n ^\n\nTypeError: Cannot read properties of undefined (reading 'label')\n at createCompletionItemWithTs (/home/raydev/.local/share/nvim/mason/packages/vue-language-server/node_modules/@vue/language-server/node_modules/@vue/language-service/lib/plugins/vue-sfc.js:184:21)\n at Object.provideCompletionItems (/home/raydev/.local/share/nvim/mason/packages/vue-language-server/node_modules/@vue/language-server/node_modules/@vue/language-service/lib/plugins/vue-sfc.js:164:25)\n at async worker (/home/raydev/.local/share/nvim/mason/packages/vue-language-server/node_modules/@vue/language-server/node_modules/@volar/language-service/lib/features/provideCompletionItems.js:128:42)\n at async Object.getCompletionItems (/home/raydev/.local/share/nvim/mason/packages/vue-language-server/node_modules/@vue/language-server/node_modules/@volar/language-service/lib/features/provideCompletionItems.js:169:25)\n at async /home/raydev/.local/share/nvim/mason/packages/vue-language-server/node_modules/@vue/language-server/node_modules/@volar/language-server/lib/register/registerLanguageFeatures.js:97:30\n at async Timeout.
I believe the error is from volar (the language server attached to vue file, not ts plugin):
... "rpc" "/path/to/bin/vue-language-server" ...
and seems unrelated here. Does vtsls crashed this time?
Oh sorry my bad, the crashed server this time is volar. It looks very similar to vtsls
Warn 17:06:55 notify.warn Client volar quit with exit code 1 and signal 0. Check log for errors: /home/raydev/.local/state/nvim/lsp.log
Btw the way I disable semanticTokensProvider is via command e.g.
:lua vim.lsp.get_active_clients()[4].server_capabilities.semanticTokensProvider = nil
4
is vtsls's id I manually checked with LspInfo
It is very weird that disabling the capability of one server will cause another server to crash... This is more like a client side issue. Could you try to disable vtsls and see if volar will crash?
Another thing I'd like to know is if other features of vtsls works normally for the new vue file after turning off semantic tokens. This could confirm that your "Could not find source file" error is related to semantic tokens request.
This is more like a client side issue. Could you try to disable vtsls and see if volar will crash?
Yes after disabled vtsls
, volar still crash
other features of vtsls works normally for the new vue file
I only use vtsls
as a lsp, at least the it's still sending messages to cmp.
oh I found an issue on vue language server: https://github.com/vuejs/language-tools/issues/4520 for that, which introduced in newest version ( released in this week )
But the vtsls
crash issue I am having for weeks, so I think it's not related, and the semanticTokensProvider
probably is why the server crashes.
Actually if I did not set semanticTokensProvider
to nil both lsp will crash, it's just vtsls
crashed first so I don't get the volar notify message. ( maybe related how nvim or noice.nvim handle the notify messages like I remembered that if print same value mulitiple times I only see one notification)
Sorry for random message, to summarize what am I saying is after set semanticTokensProvider
to nil vtsls
seems to work as expected.
I just pushed a fix https://github.com/yioneko/vtsls/commit/00f766e9bbefb9ee6dfcb7d62ba3befaf0b32b4a to not let the failed semantic token request crash the server. This is a bug inherited from the original vscode typescript extension. Note that it won't be expected to resolve this issue, the culprit for it is still unknown to me.
Thanks!
This is a bug inherited from the original vscode typescript extension.
Yeah i do remember seeing issues that people using vscode having the same issue. ( in vue language server repo )
The reason typescript-language-server
wasn't crashing here is because I've also diverged from vscode and applied similar (but different) fix there https://github.com/typescript-language-server/typescript-language-server/blob/caca0071095557ecc43d8695d922a4cf5e38a2ad/src/ts-client.ts#L484-L486
I think this issue is probably something with the vscode tsserver itself but I am hesitant to open an issue there as the issues I have seen seem specific to debugging "Workspaces" and TS versions in those workspaces and I don't know about any of that in my neovim world.
Since switching to vtsls (upgrading LazyVim) I am seeing errors like the following when opening files:
It does seem odd that it's using tsserver from my project here and not the one bundled with vtsls... but I don't know enough to know if that's a problem.
This is on a Javascript - not typescript - project. I don't remember ever seeing this issue with the old tsserver package lazyvim was using but I believe there may be other new versions of things involved. Apologies if this is not the correct place for this issue but it seemed like maybe the right place to start and hopefully someone more knowledgeable can point me in the right direction.
edit: I found the
select_ts_version
command but still get the error with the global version (5.4.5)