Duplicate errors in editor produced on language server initialization

[DanielRosenwasser]

Weird symptoms/tips I've already collected.

• Possibly only happens on early hovers when the language service first starts.
• Only happens when the editor (i.e. VS Code) first starts. Restart TS Server does not seem to produce this, but it definitely does not seem to be a VS Code issue given the trace output of the server.
• Server logs available here.
• Seems to only repro on typescript@4.7.0-dev.20220325 and doesn't repro on the previous typescript@4.7.0-dev.20220323.
  • This query may give a hint here
  • Merge diagnosticsProducing and nonDiagnosticsProducing checkers into a single checker supporting lazy diagnostics #36747 seems possibly related

---

The following code:

let lololol = 123;

lololo

Seems to produce two duplicate errors:

[DanielRosenwasser]

I figured out the failing test case. It has to do with whether semantic classification is requested before diagnostics come back. Here's a failing test case.

/// <reference path="./fourslash.ts" />

////let lololol = 123;
////
////lololo/**/

verify.encodedSemanticClassificationsLength("2020", 3);
verify.numberOfErrorsInCurrentFile(1);

If you comment away the semantic classifications call

- verify.encodedSemanticClassificationsLength("2020", 3);
+ // verify.encodedSemanticClassificationsLength("2020", 3);

then the test passes.

[DanielRosenwasser]

Okay, here's what I think happened:

• TypeScript has a bug around not deduplicating diagnostics that have related spans. @andrewbranch discovered that independently 1-2 weeks ago, but QuickFix: Fix all detected spelling errors not working #50243 was recently filed and Ignore related info in diagnostic deduplication #50309 aims to fix the problem.

• Often this was not noticed because every program had two type-checkers. On the command line, the type-checker ran in a relatively predictable fashion on entire files. In editing scenarios, any type-checking diagnostics were ignored (I think - or maybe there was a memory leak). However, in Merge diagnosticsProducing and nonDiagnosticsProducing checkers into a single checker supporting lazy diagnostics #36747, @weswigham switched to just one type-checker. It seemed suspicious when I bisected, but ultimately I don't think anything went wrong here. It just uncovered this bug in our deduplication code.

  So what I believe is happening is that an operation like semantic classification is walking/checking the visible region of the editor, and that adds new errors to the error list. When the server starts serving the geterr request, then it has that leftover error.

• This bug only shows up in certain scenarios because what part of the file you're viewing tends to affect when a semantic classifications request may come in. If you scroll away fast enough, you might not see the dupes. If you restart TS Server, the editor doesn't re-request semantic classifications right now (I touched on this at Inlay hints should be requested on all open files (similarly to diagnostics) vscode#130430 (comment) - I'm not sure if @mjbvz and @jrieken want to take an optimistic view on semantic classification, though I understand if we want to given that it can be relatively costly to recalculate on all editors).

I do think that #50309 should fix this though.