Skip to content

fix(lsp): handle window/workDoneProgress/create to prevent server crash - #3445

Open
piakdev wants to merge 1 commit into
charmbracelet:mainfrom
piakdev:fix/lsp-workdoneprogress-create-handler
Open

fix(lsp): handle window/workDoneProgress/create to prevent server crash#3445
piakdev wants to merge 1 commit into
charmbracelet:mainfrom
piakdev:fix/lsp-workdoneprogress-create-handler

Conversation

@piakdev

@piakdev piakdev commented Jul 28, 2026

Copy link
Copy Markdown

Summary

  • The client advertises window.workDoneProgress: true in its initialize capabilities (via powernap's makeClientCapabilities), which per the LSP spec grants servers permission to send window/workDoneProgress/create requests back to the client.
  • No handler was registered for this method. When a server actually sends it (e.g. typescript-language-server during project loading, before initialize even returns), the request goes unanswered and the server treats the failure as fatal — crashing the whole language server process with an unhandled ResponseError.
  • Fix: add a no-op HandleWorkDoneProgressCreate handler (same pattern as the existing no-op HandleWorkspaceConfiguration), and register handlers before calling client.Initialize() instead of after — servers may send this request during the initialize handshake itself, so registering afterward is too late for that window.

Repro

  1. Configure a typescript LSP server pointing at typescript-language-server --stdio for .js/.ts files.
  2. Pin typescript@5.9.3 locally in a workspace (needed separately since typescript@7.x no longer ships tsserver.js — unrelated issue).
  3. Run any LSP tool (lsp_symbols, lsp_references, etc.) against a file in that workspace.

Before: server crashes during init with ResponseError: no handler for method: window/workDoneProgress/create, subsequent LSP calls fail with jsonrpc2: connection is closed.

After: server initializes successfully; lsp_symbols/lsp_references return correct results.

Test plan

  • Built from this branch, ran lsp_symbols and lsp_references against a real .js file with typescript-language-server configured — both returned correct results instead of crashing.
  • go build ./internal/lsp/... compiles clean.

The client advertises window.workDoneProgress: true in its initialize
capabilities (via powernap's makeClientCapabilities), which per the LSP
spec grants servers permission to send window/workDoneProgress/create
requests. However, no handler was registered for this method, so when
a server actually sends it (e.g. typescript-language-server during
project loading, before initialize returns), the request goes
unanswered and the server treats the failure as fatal — crashing the
whole language server process with an unhandled ResponseError.

Reproduced with: typescript-language-server + typescript@5.9.3 in a
workspace. lsp_symbols/lsp_references failed with
"jsonrpc2: connection is closed" because the server had already died
during initialize.

Fix:
- Add a no-op HandleWorkDoneProgressCreate handler that returns nil,
  matching the pattern of the existing no-op HandleWorkspaceConfiguration.
- Register handlers before calling client.Initialize(), not after —
  servers may send this request during the initialize handshake itself,
  so registering afterward is too late for that window.

Verified end to end against typescript-language-server 5.3.0: symbols
and references now return correctly instead of crashing.
@charmcli

Copy link
Copy Markdown
Contributor

Thank you for your submission. We really appreciate it! Like many open-source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution. You can sign the CLA by just posting a Pull Request comment same as the below format.


I have read the Contributor License Agreement (CLA) and hereby sign the CLA.


You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants