Skip to content

[Repo Assist] Guard Ionide-specific fsharp/ notifications with client capability check#1515

Draft
github-actions[bot] wants to merge 2 commits intomainfrom
repo-assist/fix-issue-1032-custom-notifications-capability-check-a320a8ce4a28e955
Draft

[Repo Assist] Guard Ionide-specific fsharp/ notifications with client capability check#1515
github-actions[bot] wants to merge 2 commits intomainfrom
repo-assist/fix-issue-1032-custom-notifications-capability-check-a320a8ce4a28e955

Conversation

@github-actions
Copy link
Copy Markdown
Contributor

@github-actions github-actions bot commented Apr 1, 2026

🤖 This PR was created by Repo Assist, an automated AI assistant.

Summary

Fixes #1032 — prevents FSAC from sending Ionide-specific fsharp/ custom notifications to non-Ionide LSP clients (Emacs, Helix, etc.) that don't know how to handle them.

Root Cause

FSharpLspClient sends several Ionide-specific custom notifications unconditionally to all clients:

  • fsharp/notifyWorkspace
  • fsharp/notifyWorkspacePeek
  • fsharp/notifyCancel
  • fsharp/fileParsed
  • fsharp/documentAnalyzed
  • fsharp/testDetected

When non-Ionide clients (e.g., Emacs lsp-mode, Helix) receive these unexpected notifications, they may crash or behave erratically since they're not expecting these server-to-client notifications.

Fix

Added SupportsCustomFSharpNotifications flag to FSharpLspClient. Each of the above notification methods now checks this flag before sending.

The flag is set to true during Initialize only when the client sends Ionide configuration in InitializationOptions. This is a reliable signal for Ionide clients since Ionide always sends its FSharpConfigDto there; other LSP clients typically don't.

This pattern is already used for CodeLensRefresh and WindowWorkDoneProgressCreate which check ClientCapabilities before sending.

Trade-offs

  • Non-Ionide clients lose access to these custom notifications (which they don't use anyway)
  • Ionide clients retain full functionality with no behavioral change
  • Using InitializationOptions.HasValues as the Ionide detection heuristic: this is the simplest reliable signal available; alternative approaches (checking ClientInfo.Name) could be added in future if needed

Test Status

✅ Build succeeded (dotnet build src/FsAutoComplete/FsAutoComplete.fsproj -f net8.0)
✅ General unit tests passed (FSAC.general.Utils suite)

Full test suite was not run locally (too resource-intensive for this environment) — CI will validate.

Generated by 🌈 Repo Assist at {run-started}. Learn more.

To install this agentic workflow, run

gh aw add githubnext/agentics/workflows/repo-assist.md@1f672aef974f4246124860fc532f82fe8a93a57e

Only send Ionide-specific fsharp/ notifications (notifyWorkspace,
notifyWorkspacePeek, fileParsed, documentAnalyzed, testDetected, etc.)
when the client has sent Ionide configuration in InitializationOptions.

Other LSP clients (Emacs, Helix, etc.) do not expect these custom
fsharp/ notifications and may crash or behave unexpectedly when they
receive them. Using the presence of Ionide InitializationOptions as the
signal that the client is Ionide-compatible is reliable since Ionide
always sends its FSharpConfigDto there.

Fixes #1032

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
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.

Better handling of ClientCapabilities for different editors

0 participants