Repository navigation
NullReferenceException in OnInitialize on Linux when the initialize request includes workspaceFolders (v4.6.0) #2300
Description
On PSES v4.6.0 running on Linux, an LSP initialize whose params include a
workspaceFolders array throws a NullReferenceException inside the server's own
OnInitialize handler, on the path that adds the workspace folders. The handshake
does not complete -- no initialize response is returned -- so the server is unusable
for any client that sends workspaceFolders on this platform.
The same initialize, byte-for-byte, completes normally on Windows. Dropping
workspaceFolders and relying on rootUri alone avoids the exception on Linux. The
platform asymmetry is the notable part: a client whose handshake is verified on
Windows silently fails on Linux at exactly this step.
This is distinct from the rename-handler NRE (#2297 / PR #2299): different trigger
(workspaceFolders, not an omitted rename capability), a different code path, and
Linux-only rather than cross-platform.
Environment
- PSES:
v4.6.0(GitHub release assetPowerShellEditorServices.zip) - Host: PowerShell 7 (
pwsh) - OS: Linux (reproduced on the GitHub Actions
ubuntu-latestrunner); Windows is unaffected - Transport:
Start-EditorServices.ps1 -Stdio
Steps to reproduce
-
Launch PSES over stdio on Linux with
-NoLogo -NoProfile, logging to a file. -
Send an LSP
initializewhoseparamsinclude aworkspaceFoldersarray, e.g.:{ "processId": 12345, "clientInfo": { "name": "repro", "version": "1.0.0" }, "rootUri": "file:///home/runner/work/example", "workspaceFolders": [ { "uri": "file:///home/runner/work/example", "name": "workspace" } ], "capabilities": { "textDocument": { "rename": { "prepareSupport": false } } } }(The
renamecapability is declared deliberately, to keep the separate v4.6.0
PrepareRename NRE -- PrepareRename throws NullReferenceException when an LSP client omits therenamecapability (v4.6.0) #2297 -- out of the picture; this report is about
workspaceFolders.) -
Observe on Linux: no
initializeresponse is returned, and the PSES log
records aNullReferenceExceptionin theOnInitializehandler on the
workspace-folders add path. The NRE stack captured during debugging points at
PsesLanguageServer.csaround theOnInitializeworkspaceFolders handling
(line numbers should be confirmed against the v4.6.0 source by a maintainer).
The one-line delta that proves the cause
Re-send the same initialize with workspaceFolders removed and nothing else
changed:
{
"processId": 12345,
"clientInfo": { "name": "repro", "version": "1.0.0" },
"rootUri": "file:///home/runner/work/example",
"capabilities": { "textDocument": { "rename": { "prepareSupport": false } } }
}On Linux the handshake now completes and diagnostics flow. The only difference is the
presence of the workspaceFolders array.
Expected
Sending workspaceFolders on initialize -- a standard, optional LSP field -- must
not throw inside OnInitialize. The workspace-folders add path should null-guard
whatever it dereferences (treat an empty/uninitialized collection as "no folders yet")
rather than throwing, and it must behave the same on Linux as on Windows.
Context
Found while building a Claude Code plugin that drives PSES over stdio
(https://github.com/manderse21/claude-powershell-lsp). The plugin's Windows CI legs
always passed this handshake; only the Linux leg surfaced the NRE. The plugin now
omits workspaceFolders to work around it (it opens each file explicitly via
didOpen/didChange, so multi-root folders are not needed for diagnostics), but the
root cause should be fixed for any client that legitimately sends workspaceFolders
on Linux.
Activity
Guard against null workspaceFolders on initialize (PowerShell#2308)