Closed kbwo closed 1 week ago
After further investigation, I realized that the issue I described was caused by a mistake in my implementation of testing-language-server, not a bug in the codebase. I apologize for any confusion this PR may have caused.
Thanks for your job. I discovered a bug when using multiple LSP servers with nvim-lsp and have implemented a fix to address it.
When using multiple LSP servers with nvim-lsp, I encountered an issue where requests to unsupported methods cause significant delays and fail to return a proper response. Specifically, if one of the servers does not support the requested method, the request waits for a timeout before returning, leading to undesirable behavior.
For instance, I experienced this issue while using denols alongside testing-language-server, which does not support definitionProvider. When executing :call ddu#start(#{sources: [#{name: 'lsp_definition'}]}) to send a textDocument/definition request, the process waits for the 5000 ms timeout defined here, after which all LSP servers appear to return null.
This behavior seems to stem from the use of Promise.all for parallel processing, as noted here. Replacing this
Promise.all
with a for...of loop resolved the issue in my testing, ensuring correct execution. However, I understand that Promise.all is likely used to optimize performance, and switching to sequential execution might introduce performance issue.To resolve the issue without sacrificing performance, I implemented a fix that checks if the requested method is supported before invoking nvimLspRequest using
supports_method
. This approach maintains parallel processing while ensuring unsupported methods are not unnecessarily queried.