How to handle setBreakpoints path 'git:/...'?

[rjmholt]

From PowerShell/vscode-powershell#1994.

• VSCode Version: 1.34.0 a622c65 x64
• OS Version: Windows 10 1809

VSCode sends a setBreakpoints request from a OneDrive path like this:

2019-05-30 17:07:14.812 [VERBOSE] tid:5 in 'ReadMessage' C:\PowerShellEditorServices\src\PowerShellEditorServices.Protocol\MessageProtocol\MessageReader.cs: line 138
    Received Request 'setBreakpoints' with id 3
    
    {
      "command": "setBreakpoints",
      "arguments": {
        "source": {
          "name": "OneNote.ps1",
          "path": "git:/c%3A/Users/mcp/OneDrive/WindowsPowerShell/Modules/MsftGraph/OneNote.ps1?%7B%22path%22%3A%22c%3A%5C%5CUsers%5C%5Cmcp%5C%5COneDrive%5C%5CWindowsPowerShell%5C%5CModules%5C%5CMsftGraph%5C%5COneNote.ps1%22%2C%22ref%22%3A%22~%22%7D"
        },
        "lines": [
          338
        ],
        "breakpoints": [
          {
            "line": 338
          }
        ],
        "sourceModified": false
      },
      "type": "request",
      "seq": 3
    }

The PowerShell extension currently handles file:// and untitled:// schemes for this, but I haven't seen git:/ before.

I haven't been able to find any documentation on this behaviour (in issues or in VSCode docs) and my StackOverflow question hasn't gotten much attention.

Only one user has reported this, so it doesn't feel like a common feature we've missed.

My questions are:

• What does this path scheme mean?
• Does it make sense as a setBreakpoints request path?
• How should we be handling it?

[weinand]

This happens if there is a "filesystem provider" extension registered for a "git" scheme. This file system provider serves the contents for those urls and VS Code happily shows them in an editor. If the user sets a breakpoint on these "virtual" files, the underlying url is passed to the DAP breakpoint request.

In general a debug adapter (and the underlying debugger) cannot do much with this uri and should return an "unverified response".

Some extensions (e.g. Java) are actually implementing both the file system provider and the debug adapter. In this case the file system provider makes a jar- or zip file available as a file system and the debug adapter understands to set breakpoints in the individual files inside the archive.

[rjmholt]

Thanks for your help! Is there anywhere I can read up on this?

[weinand]

@rjmholt as usual you can find the FileSystemProvider API here:

vscode/src/vs/vscode.d.ts

Line 5607 in 3ce5cb0

export interface FileSystemProvider {

[weinand]

Actually, it is not a "FilesystemProvider" but a "TextDocumentContentProvider":
see

vscode/src/vs/vscode.d.ts

Line 1546 in 3ce5cb0

export interface TextDocumentContentProvider {

But the suggested approach is still the same: return an error from the DA's setBreakpoints request if you don't understand the scheme.

[rjmholt]

Ah thanks!

Actually, it is not a "FilesystemProvider" but a "TextDocumentContentProvider"

Yeah, it's the nomenclature I needed; without knowing what to call it, I was searching for somewhere that listed all the URI schemes VSCode uses and what functionality they each represent (hint hint)