-
Notifications
You must be signed in to change notification settings - Fork 92
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
Stop doing action for handles and ignore responses after shutdown #567
Stop doing action for handles and ignore responses after shutdown #567
Conversation
f4cb6df
to
e63e1e0
Compare
_ -> False | ||
|
||
logger <& LspMessage (show m) `WithSeverity` Debug | ||
when (not shutdown || allowedMethod m) $ maybe (return ()) (\f -> f msg) mAction |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this would be stronger than it needs to be. In particular, it's not a problem if we e.g. update the VFS. It's really only the config callback that's potentially problematic.
It's also not enough, since updating the configuration is complicated. This handles the didChangeConfiguration
notification, but not the response to workspace/configuration
. So if we wanted to do this, I think we should just stick the check in tryUpdateConfig
or something.
And I still think that servers should just make their config callbacks safe :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are right , it is not enough to stop the callback.
But IMO I do not see any reason to do the action before noti/req
even it is safe to do so, since the server is marked as shutdown anyway(Waitting the cleanup and exit notification, and ignoring other notification and request, it seems reasonable to ignore thoese actions
bring up by recieving the notification and request after the shutdown).🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After reading the relevant issues, Is my understanding correct about config update?
There is push model and pull model(new one) in LSP,
The pull model:
didChangeConfiguration
sent to serverworkspace/configuration
sent to client- Response of configuration sent to server, we update the config.
What we are doing here is kind of mixed:
didChangeConfiguration
sent to server, wetryChangeConfig
.workspace/configuration
sent to client- Response of configuration sent to server,
tryChangeConfig
again.
lsp/src/Language/LSP/Server/Core.hs
Outdated
logger <& NewConfig newConfigObject `WithSeverity` Debug | ||
cb <- LspT $ asks resOnConfigChange | ||
liftIO $ cb newConfig | ||
shutDown <- isShuttingDown |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
so instead of stop callback to all responses after we shutdown, we are stopping the config update callback here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You convinced me, let's not do this and instead skip both responses and actions like you suggest.
I think it is pretty counter intuitive that we are reponding with a invalid request but still do the actions. |
That's fair. What I am planning to do at some point is to entirely move all this stuff to be just default handlers for these methods. Then they would be treated uniformly. I guess also that not accepting responses is pretty reasonable. We might well expect that clients won't send responses if they've send |
Co-authored-by: Michael Peyton Jones <[email protected]>
Co-authored-by: Michael Peyton Jones <[email protected]>
Agree, this should make things better. |
Need to fix formatting |
fixed now |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great, thanks for making this better!
haskell/haskell-language-server#4153