"No typecheck results" since the 0.59.4 release

[razzmatazz]

It seems like #1082 broke fsautocomplete on some of clients.

I can confirm this on eglot/emacs and it first reported by @juergenhoetzel in fsharp/emacs-fsharp-mode#331

Server event log shows this:

[server-reply] (id:8) ERROR Wed Mar 22 08:36:13 2023:
(:jsonrpc "2.0" :id 8 :error
          (:code -32603 :message "No typecheck results for /Users/bob/src/csharp-language-server/src/CSharpLanguageServer/State.fs"))
[internal] (id:8) ERROR Wed Mar 22 08:36:13 2023:
(:message "error ignored, status set (No typecheck results for /Users/bob/src/csharp-language-server/src/CSharpLanguageServer/State.fs)" :id 8 :error -32603)
[server-reply] (id:9) ERROR Wed Mar 22 08:36:13 2023:
(:jsonrpc "2.0" :id 9 :error
          (:code -32603 :message "No typecheck results for /Users/bob/src/csharp-language-server/src/CSharpLanguageServer/State.fs"))

git bisect points me to:

ed061e685ef6b5bd41a83c4b8808e86d7753780c is the first bad commit
commit ed061e685ef6b5bd41a83c4b8808e86d7753780c
Author: Jimmy Byrd <[email protected]>
Date:   Sun Mar 19 16:37:12 2023 -0400

    Only reload projects that need and populate test runner (#1082)
    
    Co-authored-by: Chet Husk <[email protected]>

 src/FsAutoComplete.Core/AdaptiveExtensions.fs      | 290 +++++++++++++++++++++
 .../CompilerServiceInterface.fs                    |   8 +-
 src/FsAutoComplete.Core/FsAutoComplete.Core.fsproj |   3 +-
 src/FsAutoComplete.Core/paket.references           |   1 +
 .../LspServers/AdaptiveFSharpLspServer.fs          | 278 +++++++-------------
 src/FsAutoComplete/LspServers/Common.fs            |   8 +
 6 files changed, 402 insertions(+), 186 deletions(-)
 create mode 100644 src/FsAutoComplete.Core/AdaptiveExtensions.fs

and I can confirm reverting ed061e6 on main fixes the problem for me

[TheAngryByrd]

I’m guessing it’s due to e54bc7d. Can you try manually reverting the changes from that commit?

[razzmatazz]

I’m guessing it’s due to e54bc7d. Can you try manually reverting the changes from that commit?

I can confirm it is this commit that causes the issue–reverting fixes the problem.

[TheAngryByrd]

@baronfel Is this something that needs to change FSAC or should clients be sending AutomaticWorkspaceInit?

[baronfel]

Clients either need to send automatic workspace init OR do their own workspacepeek/workspaceload dance, yes. Do we know which clients are reporting errors and how they navigate things?

[juergenhoetzel]

Clients either need to send automatic workspace init OR do their own workspacepeek/workspaceload dance, yes. Do we know which clients are reporting errors and how they navigate things?

Indeed! Fixed by sending a valid :automaticWorkspaceInit t option:
Updating the configuration object to match Ionide configuration

[baronfel]

Glad we got there in the end :)