{"action":"created","issue":{"url":"https://api.github.com/repos/Microsoft/language-server-protocol/issues/185","repository_url":"https://api.github.com/repos/Microsoft/language-server-protocol","labels_url":"https://api.github.com/repos/Microsoft/language-server-protocol/issues/185/labels{/name}","comments_url":"https://api.github.com/repos/Microsoft/language-server-protocol/issues/185/comments","events_url":"https://api.github.com/repos/Microsoft/language-server-protocol/issues/185/events","html_url":"https://github.com/Microsoft/language-server-protocol/issues/185","id":208278785,"number":185,"title":"How should cancelled requests be handled?","user":{"login":"ljw1004","id":3316258,"avatar_url":"https://avatars1.githubusercontent.com/u/3316258?v=3","gravatar_id":"","url":"https://api.github.com/users/ljw1004","html_url":"https://github.com/ljw1004","followers_url":"https://api.github.com/users/ljw1004/followers","following_url":"https://api.github.com/users/ljw1004/following{/other_user}","gists_url":"https://api.github.com/users/ljw1004/gists{/gist_id}","starred_url":"https://api.github.com/users/ljw1004/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ljw1004/subscriptions","organizations_url":"https://api.github.com/users/ljw1004/orgs","repos_url":"https://api.github.com/users/ljw1004/repos","events_url":"https://api.github.com/users/ljw1004/events{/privacy}","received_events_url":"https://api.github.com/users/ljw1004/received_events","type":"User","site_admin":false},"labels":[{"id":461602247,"url":"https://api.github.com/repos/Microsoft/language-server-protocol/labels/clarification","name":"clarification","color":"708090","default":false}],"state":"closed","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2017-02-16T23:12:59Z","updated_at":"2017-04-12T11:50:06Z","closed_at":"2017-04-12T11:11:50Z","body":"The spec explains: \"A request that got canceled still needs to return from the server and send a response back. It can not be left open / hanging.\" But what should it return?\r\n\r\n__OPTION 1:__ The way I'd like to deal with this is by having the server free to send back a ResponseError with an \"OperationCancelled\" error code. But I'm too scared to do this in case VSCode responds to unknown error codes by popping up a UI dialog to the user.\r\n\r\n*REQUEST: LSP protocol should define a new `ErrorCode.OperationCancelled` number that clients of LSP should respect. For instance if the client sends a Completion request and gets back an OperationCancelled response then it'll know to simply not show completion.*\r\n\r\n__OPTION 2:__ Another way is if the server sends back an \"empty\" or \"partial\" result. This requires the server to do work to figure out, for each request, what is the smallest cheapest valid response it can give, one that won't confuse the client. And then it has to trust that the client won't cache this response (which is a valid fear for operations like autocomplete, definition and hover).\r\n\r\n__ADDITIONAL NEED:__ The LSP spec currently puts the entire burden upon the client to cancel unneeded requests. It would be better to let the LSP shoulder this burden if it wants. For instance, imagine the client sends a \"hover\" request over one location, and the user moves the mouse, and the client needs to send another \"hover\" request. We could do it by requiring the client to cancel the first request, or we could do it by having the server realize that the first request has been superseded and so cancel it on its own. The server already owns its queue of incoming requests, so the server is the cleanest place to code this logic.\r\n\r\n\r\n__Thoughts on caching__. Imagine a client which caches the results of completion or hover. How should it know whether a response should be cached or not? If the client is the only one who initiates cancellation requests, then the client must maintain a log of all outstanding cancellations, so that when it gets back a response it can avoid caching responses to cancelled requests. But if the server is the one who initiates cancellation, then the client needs some other way to know not to cache the response. I think that `ErrorCode.OperationCancelled` would be a neat way for the client to know this."},"comment":{"url":"https://api.github.com/repos/Microsoft/language-server-protocol/issues/comments/293553114","html_url":"https://github.com/Microsoft/language-server-protocol/issues/185#issuecomment-293553114","issue_url":"https://api.github.com/repos/Microsoft/language-server-protocol/issues/185","id":293553114,"user":{"login":"ljw1004","id":3316258,"avatar_url":"https://avatars1.githubusercontent.com/u/3316258?v=3","gravatar_id":"","url":"https://api.github.com/users/ljw1004","html_url":"https://github.com/ljw1004","followers_url":"https://api.github.com/users/ljw1004/followers","following_url":"https://api.github.com/users/ljw1004/following{/other_user}","gists_url":"https://api.github.com/users/ljw1004/gists{/gist_id}","starred_url":"https://api.github.com/users/ljw1004/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/ljw1004/subscriptions","organizations_url":"https://api.github.com/users/ljw1004/orgs","repos_url":"https://api.github.com/users/ljw1004/repos","events_url":"https://api.github.com/users/ljw1004/events{/privacy}","received_events_url":"https://api.github.com/users/ljw1004/received_events","type":"User","site_admin":false},"created_at":"2017-04-12T11:50:06Z","updated_at":"2017-04-12T11:50:06Z","body":"Thanks @dbaeumer!\r\n\r\nI'm working on an LSP provider for the Hack language, and LSP client for the Nuclide IDE. I'm writing the Hack server in OCaml (since that's what Hack is written on) so I'm having to implement it from scratch. And Nuclide can't take advantage of the LanguageClient either. Hence, I'm looking over every part of LSP in minute detail! And since we have an already-existing experience with Nuclide+Hack with an existing user interface, I have to make the switch to LSP won't regress anything."}}
{"actor":{"display_login":"ljw1004"}}