No workDoneProgress for command execution
See original GitHub issueUnsure if this is me doing something wrong, a bug, or just not yet implemented. I’m trying to use progress notifications for some longer running tasks (for example commands executed from code actions).
My server capabilities have workDoneProgress: true
:
{
"id": 0,
"jsonrpc": "2.0",
"result": {
"capabilities": {
"executeCommandProvider": {
"commands": [
"edit.sortMembers",
"edit.organizeImports",
"edit.sendWorkspaceEdit",
"refactor.perform"
],
"workDoneProgress": true
},
},
}
}
Then in a Code Actions response, I include this command:
{"id": 2,
"jsonrpc": "2.0",
"result": [
{
"title": "Extract Method",
"kind": "refactor.extract",
"command": {
"title": "Extract Method",
"command": "refactor.perform",
"arguments": [
"EXTRACT_METHOD",
"/Users/danny/Desktop/dart_sample/lib/refactortest.dart",
1,
30,
99,
null
]
}
}
]
}
However, the call to execute the command does not pass a workDoneToken
:
{
"jsonrpc": "2.0",
"id": 5,
"method": "workspace/executeCommand",
"params": {
"command": "refactor.perform",
"arguments": [
"EXTRACT_METHOD",
"/Users/danny/Desktop/dart_sample/lib/refactortest.dart",
1,
30,
99,
null
]
}
}
I can make the server fall back to creating its own (if the client supports them) when this happens, but I wasn’t sure if this is expected to work (if servers just fall back to creating their own tokens, I’m not sure what the benefit to the per-request tokens are).
Issue Analytics
- State:
- Created 3 years ago
- Comments:8 (8 by maintainers)
Top Results From Across the Web
Language Server Protocol Specification - 3.17
The recommended way to handle commands is to implement their execution on the server side if the client and server provides the corresponding...
Read more >tamasfe_lsp_types - Rust - Docs.rs
So executing a command requires some tool extension code. ... request is sent from the server to the clientto ask the client to...
Read more >Package org.eclipse.lsp4j - javadoc.io
A parameter literal used to pass a work done progress token. Class Summary. Class, Description. AbstractTextDocumentRegistrationAndWorkDoneProgressOptions.
Read more >RenameOptions Class (Microsoft.VisualStudio.LanguageServer ...
... renames should be checked and tested before being executed. WorkDoneProgress. Gets or sets a value indicating whether work done progress is supported....
Read more >remctld - Server for remctl, a remote command execution utility
To not background, pass -F as well. To not close standard output and error and continue using them for logging, pass -S as...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@dbaeumer am I right in assuming that just because the client has
workDoneProgress
support and the server says it would like (supports?) a token for a specific request, the client is not obliged to send one? If so, I think it’s worth adding a note to that effect in the spec to ensure clients/servers have the same expectations.My initial understanding was that if the client says it’s supported and the server then “requests” it in its capabilities, that the client would definitely send one - though I now don’t think that is the case (if it is, then this would be a bug).
Thanks!
Changes lgtm, thanks!