Usability: "source" (extension / owner) of a problem diagnostic not discoverable

Issue Type: Bug

Extensions in vscode generate “Problems” entries - and sometimes it is all but clear which extension generated a specific entry.

This makes it difficult to correctly address any such entry - e.g. by fixing the underlying issue, or by managing the extension.

As an example, take this screenshot where a “problem” is flagged:

In this screenshot, I can conveniently discover that

• application.yaml has a problem -> hm, OK, go on;
• the problem is Unknown property 'performance' -> hm, OK, go on;
• YAML_UNKOWN_PROPERTY is (apparently) the error code - eh, yes, go on, tell me?

… and that’s it. And that is a usability problem in the vscode core product (framework), because the product does not allow me to discover straight away which of the (many) installed extensions actually emitted this problem entry, anywhere.

Now, the problem entry itself offers hard-core access to the underlying JSON data used for rendering; in the above case, we get

[{
	"resource": " ... /application.yml",
	"owner": "_generated_diagnostic_collection_name_#5",
	"code": "YAML_UNKNOWN_PROPERTY",
	"severity": 4,
	"message": "Unknown property 'performance'",
	"startLineNumber": 2,
	"startColumn": 1,
	"endLineNumber": 2,
	"endColumn": 12
}]

Clearly, this is correct information, but this is not helpful information.

What is missing - either in the hard-core raw JSON data, or discoverable by being rendered, is the originator and quite literally, at least the source of the entry.

In my above example, the source field is missing from the JSON; I guess extensions may optionally set source to, say, “Java”, to flag that something related to Java is the source of the problem. In this case here, obviously the extension did not emit source, so it’s mystifying what is going on.

Now, even when some extension emits a source - let’s stick with “Java” -, I am unable to correlate this source back to a very specific originator: I am unable to identify the specific extension which generated the entry, as any extension is welcome to put anything into source. AFAICT, nothing would prevent 20 extensions to all claim they are source “Java”.

Proposal for resolution:

a) Every raw problems entry (the JSON) should always contain a reference to the true originator of that entry - where this truth is not something reported by the originator itself, but the unique identifying element as seen by the core vscode product, such as the vscode extension id: pivotal.vscode-spring-boot

b) In case the extension does not emit a source field, consider rendering the originator in place of where the source would otherwise be rendered. In my example this would then result in rendering of pivotal.vscode-spring-boot(YAML_UNKNOWN_PROPERTY) instead of (just) YAML_UNKNOWN_PROPERTY

c) Even if a source is supplied by the originator, consider making the originator conveniently available, too. It might be useful to expand the tooltip implementation in the Problems view and in the code editor, and the flyway “Show problem” hover, with functionality that allows easy discovery of the originator. This would simply access aways from having to inspect the raw JSON data.

VS Code version: Code 1.63.2 (899d46d82c4c95423fb7e10e68eba52050e30ba3, 2021-12-15T09:39:46.686Z) OS version: Linux x64 5.15.18-200.fc35.x86_64 Restricted Mode: No

System Info

Item	Value
CPUs	Intel® Core™ i7-7820HQ CPU @ 2.90GHz (8 x 2904)
GPU Status	2d_canvas: enabled gpu_compositing: enabled multiple_raster_threads: enabled_on oop_rasterization: disabled_off opengl: enabled_on rasterization: disabled_software skia_renderer: enabled_on video_decode: disabled_software vulkan: disabled_off webgl: enabled webgl2: enabled
Load (avg)	0, 0, 0
Memory (System)	31.31GB (22.24GB free)
Process Argv	–unity-launch --crash-reporter-id 80e0ae97-0bc4-4a76-8337-f435f2ec1554
Screen Reader	no
VM	100%
DESKTOP_SESSION	/usr/share/xsessions/plasmax11
XDG_CURRENT_DESKTOP	KDE
XDG_SESSION_DESKTOP	KDE
XDG_SESSION_TYPE	x11

Extensions (29)

Extension	Author (truncated)	Version
project-manager	ale	12.4.0
path-intellisense	chr	2.7.0
xml	Dot	2.5.1
gitlens	eam	11.7.0
vscode-drawio	hed	1.6.4
rest-client	hum	0.24.6
vscode-peacock	joh	4.0.0
vscode-docker	ms-	1.19.0
python	ms-	2021.12.1559732655
vscode-pylance	ms-	2022.1.5
remote-containers	ms-	0.209.6
remote-ssh	ms-	0.70.0
remote-ssh-edit	ms-	0.70.0
remote-wsl	ms-	0.63.13
vscode-remote-extensionpack	ms-	0.21.0
vscode-boot-dev-pack	Piv	0.1.0
vscode-spring-boot	Piv	1.30.0
fabric8-analytics	red	0.3.5
java	red	1.3.0
vscode-xml	red	0.18.2
vscode-yaml	red	1.3.0
vscodeintellicode	Vis	1.2.16
vscode-java-debug	vsc	0.38.0
vscode-java-dependency	vsc	0.19.0
vscode-java-pack	vsc	0.21.0
vscode-java-test	vsc	0.34.0
vscode-maven	vsc	0.35.0
vscode-spring-boot-dashboard	vsc	0.2.0
vscode-spring-initializr	vsc	0.8.0

A/B Experiments

vsliv368:30146709
vsreu685:30147344
python383:30185418
vspor879:30202332
vspor708:30202333
vspor363:30204092
vswsl492cf:30256860
pythonvspyl392:30425749
pythontb:30283811
pythonptprofiler:30281270
vshan820:30294714
vstes263:30335439
pythondataviewer:30285071
vscod805:30301674
pythonvspyt200:30340761
binariesv615:30325510
bridge0708:30335490
bridge0723:30353136
vsaa593:30376534
vsc1dst:30428979
pythonvs932:30410667
vs360:30404995
vsrem710:30416614

[shoffmeister]

I am now off to pivotal.vscode-spring-boot to report that they fix their extension, so that they emit source.

But, really, the vscode product should also add implementation, see my suggestions for resolution, at least items a) and b).

[VSCodeTriageBot]

🙂 This feature request received a sufficient number of community upvotes and we moved it to our backlog. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!