Make capability registration resilient to unresponsive clients#250
Closed
yasmewad wants to merge 1 commit into
Closed
Make capability registration resilient to unresponsive clients#250yasmewad wants to merge 1 commit into
yasmewad wants to merge 1 commit into
Conversation
Some LSP clients don't respond to client/registerCapability or client/unregisterCapability requests, which blocks lsp4j's message loop and hangs the server. This change adds .exceptionally() handlers with warning-level logging to all 6 registerCapability/unregisterCapability call sites, treating capability registration as best-effort. The server continues to function without dynamic registrations. Also removes the unused version.properties build task and startup banner from connect(), along with their now-dead imports.
Contributor
Author
|
Closing as I realized the existing binary pattern works with Kiro CLI. It was just that I was missing some setup instructions in correct order. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Some LSP clients (such as Kiro CLI) don't respond to
client/registerCapabilityorclient/unregisterCapabilityrequests, which blocks lsp4j's message loop and hangs the server. This is especially problematic
because the unregister→register chain runs on every file change, workspace folder change, and
build file save (since clients don't de-duplicate file watchers).
Per the LSP 3.17 spec, dynamic registration is optional — "Not all clients need to support
dynamic capability registration" — and
didChangeWatchedFileshas no static fallback("the current protocol doesn't support static configuration for file changes from the server
side"). The server must degrade gracefully when registration isn't available.
Changes
Best-effort capability registration: Added
registerBestEffort()andunregisterBestEffort()helper methods that wrap all 6registerCapability/unregisterCapabilitycall sites with.exceptionally()handlers. Each call sitelogs a distinct warning describing which registration failed.
Fixed unregister→register chains: Changed
thenRuntothenComposein the 3places that chain unregister then register (
didChangeWatchedFiles,didChangeWorkspaceFolders,didSave).thenRunsilently skips the re-registrationif the upstream future completes exceptionally;
thenComposeproperly composes thetwo async operations so re-registration always proceeds.
Removed unused version.properties: The
createPropertiesGradle task and startupbanner in
connect()were dead code. Removed along with their now-unused imports.Made
StubClientextensible: Removedfinalmodifier to allow test-specificsubclasses that simulate client failures.
Testing
initializedHandlesRegisterCapabilityFailure— verifies the server continues whenregisterCapabilityreturns a failed future during startupunregisterFailureDoesNotBlockReRegistration— verifies the unregister→registerchain in
didChangeWatchedFilesstill works whenunregisterCapabilityfails