Error: Could not find source file... #168
Comments
|
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 |
|
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. |
Yes, verbose logging is needed.
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:
|
|
@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):
|
|
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. 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.
The server crashed ( at least in my case ) so you need to |
|
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 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 Here's the crash log Details
[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 |
|
@RayGuo-ergou Thanks, it is much clearer now. Did you see something like |
|
Sometimes I will get this error message about 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 Details
[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 It still shows error for |
|
Sorry, it is my bad. We should use The 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 |
After this I got these errors ( by searching with Details
[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. (/home/raydev/.local/share/nvim/mason/packages/vue-language-server/node_modules/@vue/language-server/node_modules/@volar/language-server/lib/register/registerLanguageFeatures.js:414:32)\n\nNode.js v20.15.0\n" |
|
I believe the error is from volar (the language server attached to vue file, not ts plugin): 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 Btw the way I disable semanticTokensProvider is via command e.g.
|
|
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. |
Yes after disabled
I only use
|
|
oh I found an issue on vue language server: vuejs/language-tools#4520 for that, which introduced in newest version ( released in this week ) |
|
Actually if I did not set Sorry for random message, to summarize what am I saying is after set |
|
I just pushed a fix 00f766e 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!
Yeah i do remember seeing issues that people using vscode having the same issue. ( in vue language server repo ) |
|
The reason |
|
I've somehow managed to trigger a similar error again, here's the debug log: The file in question exists, is readable, has no weird encoding or anything like that. Not sure if this helps... |
|
The error is from the server itself and not the same. It is triggered when the client requests a feature without notifying the server the document is opened by |
|
Ah, I see. Thanks for the explanation. I'm not seeing a didClose/cancelRequest message because TSServer crashed before that. I'm seeing lots of those errors and then a SIGTERM: That error was to be "expected" - my mistake while writing the file in question. I wouldn't expect TSServer to die from that, tho (then again, no idea if that's regular execution or not). Should that be reported upstream or am I just holding it wrong? :D |
Did you see
I believe these errors are from the eslint server... https://github.com/microsoft/vscode-eslint/blob/edc9685bcda26462dc52decce213167af8d2b25d/server/src/eslint.ts#L1451-L1454, and not related here. Tsserver do not throw error like that.
Though the log level for this is |
|
Ok, I've tried diving a little deeper into it since the problem still persists, pretty much on every TS project I use. I still cannot pin-point why it's happening or what exactly triggers it. I've logged a full close and open cycle of a file that exhibits the error. I'm seeing several Here's some more logs: |
|
I see. It's really hard to troubleshoot a problem cannot be stability reproduced. But based on the logs we can confirm the triggering reason for the Strictly speaking, it's not a good behavior that the server throws error on file not opened since that has not been clarified in LSP and the error could trigger very frequently leading to a bad user experience. Therefore I've pushed a change 23f922e to suppress this type of error in case that client does not behave what the server expects (sending didopen notification before requesting any features). However, that change doesn't mean to resolve this problem, it's just suppressing the annoying errors. You won't get any language features like completion working on the file not notified to have been opened. The issue should go to the client side but I'm afraid that they won't give a shot on this if no minimal reproduction steps provided. I've tried to inspect the nvim LSP client code related to this, here are some of my suggestions (hopefully useful):
local function reattch_workaround()
local bufnr = vim.api.nvim_get_current_buf()
vim.schedule(function()
if not vim.api.nvim_buf_is_loaded(bufnr) then
return
end
for _, client in pairs(vim.lsp.get_clients({ name = "vtsls" })) do
vim.lsp.buf_detach_client(bufnr, client.id)
if client.attached_buffers[bufnr] then
-- if triggered, this is a bug in core
client.attached_buffers[bufnr] = nil
end
if not client.initialized then
-- if triggered, this is (possibly) a bug in core
client.initialized = true
end
vim.lsp.buf_attach_client(bufnr, client.id)
-- ensure the didOpen request in sent
client.notify(vim.lsp.protocol.Methods.textDocument_didOpen, {
textDocument = {
version = vim.lsp.util.buf_versions[bufnr],
uri = vim.uri_from_bufnr(bufnr),
languageId = vim.bo[bufnr].filetype,
text = vim.lsp._buf_get_full_text(bufnr),
},
})
end
end)
end
-- hack on vim.notify to trigger the workaround
-- you can also bind it to a key mapping
local notify = vim.notify
vim.notify = function(...)
notify(...)
local msg = select(1, ...)
if string.find(msg, "vtsls.*Cannot find document") == nil then
return
end
reattch_workaround()
end |
|
Thank you, so much @yioneko for the super comprehensive reply.
I've used neovim nightly all day and haven't had the issue come up. I'm inclined to say that the bug you mentioned in 0.10 seems to be fixed in nightly but I'll give it a couple of more hours to see if it starts popping up again. Out of curiosity, do you happen to have a commit over on the neovim repo that fixes it?
That's interesting, I haven't had the time to test that one out but will definitely try should the issue resurface again. edit: after about a week: nightly completely fixed it I have no issues whatsoever anymore. |
|
Just found this issue microsoft/vscode#214226 not sure if this is related( because it is on vscode ), but the error does seem identical tho. |
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_versioncommand but still get the error with the global version (5.4.5)The text was updated successfully, but these errors were encountered: