(Experimental duplicate detection)
Thanks for submitting this issue. Please also check if it is already covered by an existing one, like:

• Diagnostics created by tasks aren't accessible to extensions (#47292)
• Allow diagnostics messages to have markdown (or formatted text) content (#54272)
• Add way for extensions to signal that diagnostics are actively being computed but have not been returned yet (#54273)
• Allow MarkedStrings in Diagnostics (#20232)
• Diagnostics should support data field (#24682)

For example, take the following code (which is representative of what the Elm and Flow extensions are currently doing):

So, if these extension always create a new collection, with disposing the old one it's likely that. The UI is likely deduping makers but the model won't. So, with the sample above, you are always adding new diagnostics but never removing them. Calling clear on the collection is local to that instance and those instances aren't shared because they share the name.

So, please check with your extension(s).

to create a single DiagnosticCollection for the lifetime of the extension (as opposed to re-creating it over and over again), then things behave as expected:

Sorry, only saw that now. Yeah, we don't dedupe in the model and I don't think it's the correct thing to do.

We have a great developer community over on slack where extension authors help each other. This is a great place for you to ask questions and find support.

Happy Coding!

@jrieken Apologies. My original repro was probably too simple. If I modify the diagnostic message like the following:

let num = 0;

...

// Notice that I'm changing the error message each time to prevent de-duplication
errors.set(d.uri, [new vscode.Diagnostic(new vscode.Range(0, 0, 0, 0), `Failure${num++}`)]);

And save the document a few times, I see the following in the Problems pane:

And I see the following output from calling getDiagnostics(uri):

Are you saying that the Problems pane is de-duplicating diagnostics based on some kind of message pattern? In the above case, these diagnostics have different messages, and so I'm not sure why they would be removed from the UI if they're still in the model.

Even further, if I call the getDiagnostics() overload, instead of getDiagnostics(uri), then the old diagnostics are gone! So this appears to be a bug with the getDiagnostics(uri) method specifically. Is it possible that the Problems pane is consuming the getDiagnostics() method (workspace-wide retrieval vs. document-specific) or equivalent, and that's why it's immune to this issue?

Even further, if I call the getDiagnostics() method, instead of getDiagnostics(uri), then the old diagnostics are gone!

Sure about that? Both methods loop over the same collection of DiagnosticsCollections... Be aware of the different return types.

So this appears to be a bug with the getDiagnostics(uri) method specifically.

As long as you create more and more collections without disposing old ones, diagnostics pile up and the getDiagnostics-function returns them all. That's how it should be.

Is it possible that the Problems pane is consuming the getDiagnostics() method (workspace-wide retrieval vs. document-specific), and that's why it's immune to this issue?

Fair question. Taking another look and turns out that the name you provide when creating a collection is actually used as some kind of identifier. That makes the old markers disappear (be overwritten). I'd say that's actually a bug and I will make a code accordingly, e.g. when using a name that's already being used, we will bring a warning and use a different internal identifier.

@jrieken Ah yeah, you're right. Both overloads of getDiagnostics have this same behavior. Apologies for saying otherwise!

I have now added a warning when a diagnostic collection with the same name is created (and it will use a different owner). Interestingly, TypeScript triggers this warning because for JS and TS the same name/owner is being used. According to @mjbvz this is because of tasks and problem matching. @dbaeumer can you provide insights.

Using a different owner for TypeScript and JavaScript works as long as users don't use a TSC task to check JS code. If they do the best we can do is to have different problem matchers with different IDs. I would suggest we simply make the change in the TS extension and then see if users get hit by tasks on pure JS projects (which I think is a very limited number of users in total).

Ok. Alternatively, TypeScript can use one diagnostics collection (named typescript) for both languages

I leave my change as it and leaving up to you two to fix this

+1 for @jrieken suggestion since it is the right fix to do since JS and TS will not overlap.

Here's the change that unified the diagnostics in the first place b945973 which was made to fix #48709. It was done for exactly the reason you detailed: using tsc to check javascript code.

Using a single collection will require work since we make some assumptions about having separate ones for JS and TS (it lets us handle the typescript.validate and javascript.validate settings more easily)

@mjbvz thanks!