Problems from main vscode build or extensions build can be shown, not both when a file is closed

[roblourens]

Testing #119471

• Follow steps in the linked item
• Have compile errors in the extension build and also the main build
• Open one of the files - the problems pane has errors from both builds
• Close that file - the problems pane only has errors from one of the builds

Seems random which one it is

[meganrogge]

for files when this doesn't work, it's returning here

vscode/src/vs/workbench/contrib/tasks/common/problemCollectors.ts

Lines 434 to 436 in 4a130c4

	if (!markerEvent.includes(modelEvent.uri) || (this.markerService.read({ resource: modelEvent.uri }).length !== 0)) {
	return;
	}

with the first of the conditions as true

[meganrogge]

The issue is that the schemes are different here - git vs file

[meganrogge]

when it succeeds and restores the problems on close, the modelEvent has the correct scheme of file

[meganrogge]

I think that check is actually working as designed since git resources are just redundant

[meganrogge]

This might be a part of the issue

vscode/src/vs/workbench/contrib/tasks/common/problemCollectors.ts

Lines 167 to 170 in 4a130c4

	case ApplyToKind.closedDocuments:
	return !this.openModels[(await result.resource).toString()];
	default:
	return true;

[meganrogge]

I believe what's happening is a race condition between the listener of modelService.onModelRemoved in AbstractProblemCollector and that in its child, WatchingProblemCollector.

vscode/src/vs/workbench/contrib/tasks/common/problemCollectors.ts

Lines 96 to 98 in 4a130c4

	this.modelService.onModelRemoved((model) => {
	delete this.openModels[model.uri.toString()];
	}, this, this.modelListeners);

vscode/src/vs/workbench/contrib/tasks/common/problemCollectors.ts

Lines 426 to 446 in 4a130c4

	this.modelListeners.add(this.modelService.onModelRemoved(modelEvent => {
	let markerChanged: IDisposable | undefined =
	Event.debounce(this.markerService.onMarkerChanged, (last: readonly URI[] | undefined, e: readonly URI[]) => {
	return (last ?? []).concat(e);
	}, 500)(async (markerEvent) => {
	markerChanged?.dispose();
	markerChanged = undefined;
	if (!markerEvent.includes(modelEvent.uri) || (this.markerService.read({ resource: modelEvent.uri }).length !== 0)) {
	return;
	}
	const oldLines = Array.from(this.lines);
	for (const line of oldLines) {
	await this.processLineInternal(line);
	}
	});
	setTimeout(async () => {
	markerChanged?.dispose();
	markerChanged = undefined;
	}, 600);
	}));

The onModelRemoved in WatchingProblemCollector calls processLineInternal which calls shouldApplyMatch, which depends upon upon the one in AbstractProblemCollector happening first to update openModels. Sometimes (often) that doesn't happen which results in shouldApplyMatch returning the wrong value so the matches don't get applied.

vscode/src/vs/workbench/contrib/tasks/common/problemCollectors.ts

Lines 376 to 386 in 4a130c4

	let shouldApplyMatch = await this.shouldApplyMatch(markerMatch);
	if (shouldApplyMatch) {
	this.recordMarker(markerMatch.marker, owner, resourceAsString);
	if (this.currentOwner !== owner || this.currentResource !== resourceAsString) {
	if (this.currentOwner && this.currentResource) {
	this.deliverMarkersPerOwnerAndResource(this.currentOwner, this.currentResource);
	}
	this.currentOwner = owner;
	this.currentResource = resourceAsString;
	}
	}

vscode/src/vs/workbench/contrib/tasks/common/problemCollectors.ts

Lines 161 to 172 in 4a130c4

	protected async shouldApplyMatch(result: ProblemMatch): Promise<boolean> {
	switch (result.description.applyTo) {
	case ApplyToKind.allDocuments:
	return true;
	case ApplyToKind.openDocuments:
	return !!this.openModels[(await result.resource).toString()];
	case ApplyToKind.closedDocuments:
	return !this.openModels[(await result.resource).toString()];
	default:
	return true;
	}
	}

[meganrogge]

deliverMarkersPerOwnerAndResourceResolved isn't getting called when on file close the problems don't reappear for it

below the first half is the logs that happen when they do reappear and the second is when they don't

[meganrogge]

When I close a document and its errors don't get persisted, neither of these lines are getting hit

[alexr00]

If I recall correctly, the problem stems from the fact that the VS Code build tasks only shows problems for closed files and we rely on the Typescript extension to provide problems for open files. To prevent duplicate problems in this setup (getting problems from two different sources) we use the same owner for both sets of problems. This is further complicated by there really being three sources for problems: the Typescript extension, the core build task, and the extension build task. The unfortunate side effect of this is that one or the other source can overwrite problems from the other. A real solution would require some kind of work in the markers service (see discussion starting from #124780 (comment)).

[alexr00]

Moving out of the May milestone.

[russelldavis]

It doesn't fix the underlying issue, but there's a simple workaround for this for the vscode repo -- run the main build and the extension build as a single task. There's already an npm script for that (watchd) so it's a pretty simple change -- PR at #183174