Sometimes problem matchers don't find the end pattern on Windows

[Tyriar]

I have the following task.json:

{
  "type": "npm",
  "script": "watch-esbuild",
  "group": "build",
  "isBackground": true,
  "problemMatcher": {
    "fileLocation": "relative",
    "pattern": [
      // Doesn't match esbuild errors, just here to get background to work
      {
        "regexp": "^([^\\\\s].*)\\\\((\\\\d+,\\\\d+)\\\\):\\\\s*(.*)$",
        "file": 1,
        "location": 2,
        "message": 3
      }
    ],
    "background": {
      "activeOnStart": true,
      "beginsPattern": "build started",
      "endsPattern": "build finished"
    }
  },
  "presentation": {
    "group": "vscode"
  }
},

Sometimes this happens where the problem matcher never stops it's progress indicator:

This is because of conpty causing onLineData to fire something unexpected. Given that this problem isn't likely to go away from conpty, what if on Windows we verified the last line was actually checked after the terminal has been idle for a little bit, that way the problem would be self correcting for a lot of cases shortly after builds finish (provided the end pattern was the last line).

Version: 1.69.0-insider (user setup)
Commit: fbf1cf3
Date: 2022-06-17T05:16:33.731Z
Electron: 18.3.3
Chromium: 100.0.4896.160
Node.js: 16.13.2
V8: 10.0.139.17-electron.0
OS: Windows_NT x64 10.0.22000

[alexr00]

This seems like a reasonable approach. What is the unexpected line data that's getting fired?

[Tyriar]

Not sure, repro is unclear and you need escape sequence logging enabled when it happens to see what it would be

[r3m0t]

I having the same issue, are you accepting pull requests for this?

[Tyriar]

@r3m0t you could give it a shot as we probably won't be looked at it soon 👍

Code pointer to the terminal task code: https://github.com/microsoft/vscode/blob/8f58d9df260144d72545f66a964e88232d751f5f/src/vs/workbench/contrib/tasks/browser/terminalTaskSystem.ts

@meganrogge can you give a pointer for where problem matchers get evaluated?

[meganrogge]

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

Lines 142 to 168 in 3bed084

	protected tryFindMarker(line: string): IProblemMatch | null {
	let result: IProblemMatch | null = null;
	if (this.activeMatcher) {
	result = this.activeMatcher.next(line);
	if (result) {
	this.captureMatch(result);
	return result;
	}
	this.clearBuffer();
	this.activeMatcher = null;
	}
	if (this.buffer.length < this.bufferLength) {
	this.buffer.push(line);
	} else {
	const end = this.buffer.length - 1;
	for (let i = 0; i < end; i++) {
	this.buffer[i] = this.buffer[i + 1];
	}
	this.buffer[end] = line;
	}
	result = this.tryMatchers();
	if (result) {
	this.clearBuffer();
	}
	return result;
	}

[r3m0t]

Looks like my issue is a separate one, webpack isn't emitting newlines so onLineData isn't fired- (I have process.env.WEBPACK_CLI_START_FINISH_FORCE_LOG set to "1" )

https://github.com/webpack/webpack-cli/blob/d390d32fe0f2491c5cc3a8dfae3ccc3962a5911b/packages/webpack-cli/src/plugins/CLIPlugin.ts#L58-L61

esbuild does emit newlines as shown in @Tyriar 's screenshot and here:

https://github.com/evanw/esbuild/blob/698898f86615a69f52d2e00681a13fe2b8635e88/pkg/api/api_impl.go#L1269

I didn't repro @Tyriar 's issue. I think I'll just submit a PR to webpack to solve my issue.

[Tyriar]

This issue seems to originate from an upstream component and is not something VSCode can fix by making a change to our code. As such, I will go ahead and close it. Please try to reproduce in Windows Terminal and report to microsoft/terminal with repro steps.

If you cannot reproduce in Windows Terminal, chances are it's fixed in a later version of Windows. You can read more about how we consume conpty here. Additionally, soon we plan on shipping conpty v2 with VS Code which should bring our behavior in line with Windows Terminal. Thanks for understanding.

/label upstream terminal-conpty windows