vscode-powershell: Viewing Problems Pane causes PowerShell Session to terminate

System Details

Version: 1.33.0-insider (user setup)
Commit: 5688d00dd592a165530a82945c4ade4dad6b01e7
Date: 2019-03-25T06:19:55.474Z
Electron: 3.1.6
Chrome: 66.0.3359.181
Node.js: 10.2.0
V8: 6.6.346.32
OS: Windows_NT x64 10.0.17763

PowerShell Extension Version: 1.11.0
PSVersionTable:
Name                           Value
----                           -----
PSVersion                      5.1.17763.134
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.17763.134
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Issue Description

I recently implemented some new Problem Matchers for detecting issues with Pester tests. However, when displaying the matched problems in the Problems Pane, the PowerShell extension’s session terminates prompting whether I want to restart the session or not. This only started occurring after I put in place these problem matchers. The problems pane correctly shows all problems found by the new matchers, so I don’t believe this to be a matcher problem at this time.

For reference, here’s one of the task configurations in my task.json file with the new problem matcher:

{
  "label": "Run All Tests",
  "group": "test",
  "type": "shell",
  "command": ".\\build\\build.ps1 -Task Test",
  "presentation": {
    "reveal": "always",
    "panel": "new"
  },
  "problemMatcher": [
    {
      "owner": "powershell",
      "fileLocation": ["absolute"],
      "severity": "error",
      "pattern": [
        {
          "regexp": "^\\s*Error:\\s+(.*)$",
          "message": 1
        },
        {
          "regexp": "^\\s+at\\s+[^,]+,\\s*(.*?):\\s+line\\s+(\\d+)$",
          "file": 1,
          "line": 2
        }
      ]
    },
    {
      "owner": "powershell",
      "fileLocation": ["absolute"],
      "severity": "warning",
      "pattern": [
        {
          "regexp": "^\\s*# TODO: \\(Pester::Pending\\)$",
          "message": 0
        },
        {
          "regexp": "^\\s*at\\s+[^,]+,\\s*(.*?):\\s+line\\s+(\\d+)$",
          "file": 1,
          "line": 2
        }
      ]
    },
    {
      "owner": "powershell",
      "fileLocation": ["absolute"],
      "severity": "warning",
      "pattern": [
        {
          "regexp": "^\\s*>>> No matching step definition found.$",
          "message": 0
        },
        {
          "regexp": "^\\s*at\\s+(.*): line (\\d+)$",
          "file": 1,
          "line": 2
        }
      ]
    }
  ]
}

I just noticed now that I used the following in some of the matchers: "message": 0. The intent was to use the entire regular expression match for the message. But perhaps this itself is the issue? I’m going to submit this issue as is, but I’m going to try one more thing to see if this resolves the issue. If it works, I’ll post an update (and possibly close the issue).

Expected Behaviour

The PowerShell session should not crash when viewing problems in the Problems Pane according to registered problem matchers.

Actual Behaviour

The PowerShell session is crashing when viewing problems in the Problems Pane for registered problem matchers.

Attached Logs

There is an exception in the editor services log at the bottom due to something with reading JSON. So, it’s likely there is an issue with the problem matcher definitions above.

EditorServices.log vscode-powershell.log

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 19 (1 by maintainers)

Most upvoted comments

broken PowerShell code causing the extension to crash.

But that shouldn’t happen. And BTW it turns out the JSON deserializer can handle it. I copied that msg to PS and decoded it with ConvertFrom-Json and that works. It crashes because our schema (type) for Position expects an int but technically the LSP spec (being JavaScript based) states number which can be int or floating point. Still that is a whacked value and if that number is coming from VSCode - which it appears to be - seems like maybe it’s a bug in VSCode.