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

[shoffmeister]

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 (899d46d, 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(R) Core(TM) 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).

[shoffmeister]

The "offender" above now knows this as spring-projects/sts4#725

[sandy081]

It is extension's responsibility to set the source of the extension so that users will be aware of that. And most of the extensions are playing this correctly and would recommend to file issue against those which are not doing it.

[shoffmeister]

FWIW, I see vscode as a framework to assist users and extension developers. The current state of the framework helps neither party.

I do agree that extension developers should write correct extensions (see my bug report against Spring), but that does not, IMHO, relieve the framework from the duty to protect (or enforce, or...)

[wbt]

When software on your system isn't behaving as it should, saying "but it's the fault of that software" is a cheap way to shift off the burden the platform should have to help in at least discovering and identifying which software is causing the issue, in a way that can't be faked by misbehaving software. I don't think we'd be happy if Windows Defender just said "It's malware's job to let you know it's malware. We shouldn't need to do anything to help you identify what's really causing an issue."

As another example, when something's eating up 100% of our CPU etc., we look to Task Manager or Process Explorer type tools to find out what. Those tools exist for a reason! The philosophy of just saying it's the responsibility of misbehaving software to report accurately on itself is not a good one for a platform like this.

would recommend to file issue against those which are not doing it.

How would you even know which extension to file a bug against for this purpose (or that or any other) when VSCode doesn't provide a way for you to find out which one is flagging a problem?

[wbt]

Tagging @tvvignesh from #111443 if you and/or colleagues want to thumbs-up the backlog candidate!

[freereuben]

@shoffmeister you should upvote your own proposal and get colleagues involved if you want to see it happen!

[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!

[shoffmeister]

Just today I ran into a case where this issue really really hurts again. It's best to demonstrate this with an example:

How am I, a simple user, expected to find the extension which produces this error diagnostic:

[{
	"resource": "myfile.yaml",
	"owner": "_generated_diagnostic_collection_name_#0",
	"severity": 8,
	"message": "String is not a URI: URI expected.",
	"source": "yaml-schema: Validation schema for OpenAPI Specification 3.0.X.",
	"startLineNumber": 7,
	"startColumn": 10,
	"endLineNumber": 7,
	"endColumn": 12
}]

I am the first to agree that the extension ought to declare itself in a reasonable way, somewhere, somehow. But, as is quite evident from the above, it does not.

With vscode as the framework not injecting a marker itself, it's ... just horrible.

Even if extensions strive to be kind and friendly, the situation does not improve all that much:

[{
	"resource": "/Untitled-1",
	"owner": "spectral",
	"code": "parser",
	"severity": 4,
	"message": "Using tabs can lead to unpredictable results",
	"source": "spectral",
	"startLineNumber": 2,
	"startColumn": 1,
	"endLineNumber": 2,
	"endColumn": 1
}]

I happen to have a reasonably qualified guess that the origin of that diagnostic is the extension stoplight.spectral - but that's totally happenstance and luck, even though the vendor of the extension actually makes an attempt to be friendly.

So, in short, the only recourse to this dilemma that I see is the framework code taking action, i.e. literally Visual Studio Code forcibly adding a reference to the extension, to every diagnostic entry.