-
Notifications
You must be signed in to change notification settings - Fork 131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Upon receiving a workspace/symbol request, the server panic if Capabilities.WorkspaceSymbolClientCapabilities.symbolKind isn't set by the client during initialize #1349
Comments
Hi @shellwhale The spec says the following about the optional
We'll have to find what these are and maybe encode these kinds into a slice of defaults we can then pass in cases where I can look into a patch but I'd still like to establish the real-world impact. |
Well, I was personally impacted! I was trying out to develop a client for the first time and came across the issue. I lost quite a bit of time wondering what could I be doing wrong. I did not include my own client code in the issue for the sake of simplicity, I used the test so that the bug is easily reproducible. I saw the symbolKind values are here in the spec, so in our case a default slice like you said with values I also just noticed that they are defined here So is that what we are looking for? var defaultSymbols protocol.SymbolKind = []protocol.SymbolKind{protocol.File, protocol.Array} I'd gladly make a PR for this but I'm not sure yet where we should put the default slice into. |
Understood, to clarify - I wasn't implying this isn't worth fixing, I am just trying to assess the severity/impact of the bug so we can prioritise it alongside other work. Also thank you for the report and for finding the bug.
That would be most appreciated, thanks for the offer!
Yes, pretty much. The way I would interpret the comment in the spec
is all kinds between var defaultSymbols = []protocol.SymbolKind{
protocol.File,
protocol.Module,
protocol.Namespace,
protocol.Package,
protocol.Class,
protocol.Method,
protocol.Property,
protocol.Field,
protocol.Constructor,
protocol.Enum,
protocol.Interface,
protocol.Function,
protocol.Variable,
protocol.Constant,
protocol.String,
protocol.Number,
protocol.Boolean,
protocol.Array,
} |
Hi! I'm encountering this issue consistently when using the Helix editor. This makes using the LSP quite hard because it will crash on every Here are the requests from the client that crash the LSP: {
"jsonrpc": "2.0",
"method": "workspace/symbol",
"params": { "query": "" },
"id": 4
} {
"jsonrpc": "2.0",
"method": "textDocument/documentSymbol",
"params": {
"textDocument": {
"uri": "file:<filepath>.tf"
}
},
"id": 1
} |
We just released a new version of the language server 0.32.7. This fixes the reported bug. Thank you for the report @shellwhale |
I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. |
Language Server Version
v0.31.4
Terraform Version
Terraform v1.5.4 on windows_amd64, Terraform v1.5.4 on linux_amd64
Client Version
terraform-ls/internal/langserver/handlers/workspace_symbol_test.go@TestLangServer_workspace_symbol_basic
Terraform Configuration
Steps to Reproduce
terraform-ls/internal/langserver/handlers/workspace_symbol_test.go
TestLangServer_workspace_symbol_basic
functiongo test -timeout 30s -run ^TestLangServer_workspace_symbol_basic$ github.com/hashicorp/terraform-ls/internal/langserver/handlers
It is worth mentioning that the error also occurs upon receiving a
textDocument/documentSymbol
request. There is also a test for it interraform-ls/internal/langserver/handlers/symbols_test.go
. The error is reproducible by removing lines 44 (included) to 58 (included).Expected Behavior
Expected some form of error handling to prevent the server crash inferred by the client and inform the user that some values should be set. Or have some default values that prevent the server crash. I'm not familiar enough with the Language Server Protocol Specification to know which one is the way to go.
Actual Behavior
The server panics with the following message to the console :
panic: runtime error: invalid memory address or nil pointer dereference
Gist
https://gist.github.com/shellwhale/a7d2f84e92838d4b1e4a01d921eebc99
Workarounds
No response
References
No response
Help Wanted
Community Note
The text was updated successfully, but these errors were encountered: