Funky path causing PSES crash

[rkeithhill]

I've been editing the PowerShell build.psm1 file (PowerShell folder open in VSCode) and I've been noticing PSES crash after some period of time.

This is on VSCode 1.17.2 x64, PSES 1.5.0 on Windows 10 FCU.

Also, I might have been editing in one of the Git diff windows.

Here's the relevant part of the log:

11/4/2017 5:29:46 PM [VERBOSE] - Method "ReadMessage" at line 123 of C:\projects\powershelleditorservices\src\PowerShellEditorServices.Protocol\MessageProtocol\MessageReader.cs

    Received Request 'textDocument/documentHighlight' with id 221

11/4/2017 5:29:46 PM [VERBOSE] - Method "ResolveFilePath" at line 354 of C:\projects\powershelleditorservices\src\PowerShellEditorServices\Workspace\Workspace.cs

    Resolved path: git:/c%3A/Users/Keith/GitHub/rkeithhill/PowerShell/build.psm1?%7B%22path%22%3A%22c%3A%5C%5CUsers%5C%5CKeith%5C%5CGitHub%5C%5Crkeithhill%5C%5CPowerShell%5C%5Cbuild.psm1%22%2C%22ref%22%3A%22~%22%7D

11/4/2017 5:29:46 PM [VERBOSE] - Method "WriteMessage" at line 61 of C:\projects\powershelleditorservices\src\PowerShellEditorServices.Protocol\MessageProtocol\MessageWriter.cs

    Writing Response 'textDocument/documentHighlight' with id 221

11/4/2017 5:29:47 PM [VERBOSE] - Method "ReadMessage" at line 123 of C:\projects\powershelleditorservices\src\PowerShellEditorServices.Protocol\MessageProtocol\MessageReader.cs

    Received Request 'textDocument/definition' with id 222

11/4/2017 5:29:47 PM [VERBOSE] - Method "ResolveFilePath" at line 354 of C:\projects\powershelleditorservices\src\PowerShellEditorServices\Workspace\Workspace.cs

    Resolved path: git:/c%3A/Users/Keith/GitHub/rkeithhill/PowerShell/build.psm1?%7B%22path%22%3A%22c%3A%5C%5CUsers%5C%5CKeith%5C%5CGitHub%5C%5Crkeithhill%5C%5CPowerShell%5C%5Cbuild.psm1%22%2C%22ref%22%3A%22~%22%7D

11/4/2017 5:29:47 PM [ERROR] - Method "OnListenTaskCompleted" at line 391 of C:\projects\powershelleditorservices\src\PowerShellEditorServices.Protocol\MessageProtocol\ProtocolEndpoint.cs

    ProtocolEndpoint message loop terminated due to unhandled exception:
    
    System.AggregateException: One or more errors occurred. ---> System.UriFormatException: Invalid URI: The hostname could not be parsed.
       at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
       at Microsoft.PowerShell.EditorServices.Protocol.Server.LanguageServer.GetFileUri(String filePath)
       at Microsoft.PowerShell.EditorServices.Protocol.Server.LanguageServer.<HandleDefinitionRequest>d__33.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at Microsoft.PowerShell.EditorServices.Protocol.MessageProtocol.MessageDispatcher.<DispatchMessage>d__7.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at Microsoft.PowerShell.EditorServices.Protocol.MessageProtocol.ProtocolEndpoint.<ListenForMessages>d__36.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at Microsoft.PowerShell.EditorServices.Utility.AsyncContext.Start(Func`1 asyncMainFunc, ILogger logger)
       at System.Threading.Tasks.Task.Execute()
       --- End of inner exception stack trace ---
    ---> (Inner Exception #0) System.UriFormatException: Invalid URI: The hostname could not be parsed.
       at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
       at Microsoft.PowerShell.EditorServices.Protocol.Server.LanguageServer.GetFileUri(String filePath)
       at Microsoft.PowerShell.EditorServices.Protocol.Server.LanguageServer.<HandleDefinitionRequest>d__33.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at Microsoft.PowerShell.EditorServices.Protocol.MessageProtocol.MessageDispatcher.<DispatchMessage>d__7.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at Microsoft.PowerShell.EditorServices.Protocol.MessageProtocol.ProtocolEndpoint.<ListenForMessages>d__36.MoveNext()
    --- End of stack trace from previous location where exception was thrown ---
       at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()
       at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task)
       at Microsoft.PowerShell.EditorServices.Utility.AsyncContext.Start(Func`1 asyncMainFunc, ILogger logger)
       at System.Threading.Tasks.Task.Execute()<---
``

[TylerLeonhardt]

Interesting! Thanks Keith! In any case, we might need to catch this error.

[TylerLeonhardt]

I've seen a couple of things with this issue. One is this System.UriFormatException: Invalid URI: The hostname could not be parsed. The other, the PathTooLongException that we see a lot of in PowerShell/vscode-powershell#1195 .

I think these two exceptions are ones we need to handle. My gut says that if we catch these in:
https://github.com/PowerShell/PowerShellEditorServices/blob/master/src/PowerShellEditorServices/Workspace/Workspace.cs#L383-L409

It might fix the issue.

From the log @rkeithhill pasted in this issue, we might want to add some better logic here to catch some exceptions as well:
https://github.com/PowerShell/PowerShellEditorServices/blob/master/src/PowerShellEditorServices.Protocol/Server/LanguageServer.cs#L1335-L1342

[rkeithhill]

My first approach to these sorts of problems was to just handle the exceptions but I think @daviwil believes there is a problem with how we handle file URIs.

[rkeithhill]

Here is yet another case of PSES not understanding a file URI. In this case the URI is git-file-viewer://./build.47321a.ps1 which is created by GitLens when viewing a previous version of a file. This results in this crash:

Invalid URI: The hostname could not be parsed.
   at System.Uri.CreateThis(String uri, Boolean dontEscape, UriKind uriKind)
   at Microsoft.PowerShell.EditorServices.CodeLenses.ReferencesCodeLensProvider.GetFileUri(String filePath)
   at Microsoft.PowerShell.EditorServices.CodeLenses.ReferencesCodeLensProvider.<>c.<ResolveCodeLensAsync>b__4_1(SymbolReference r)
   at System.Linq.Enumerable.WhereSelectListIterator`2.MoveNext()
   at System.Linq.Buffer`1..ctor(IEnumerable`1 source)
   at System.Linq.Enumerable.ToArray[TSource](IEnumerable`1 source)
   at Microsoft.PowerShell.EditorServices.CodeLenses.ReferencesCodeLensProvider.<ResolveCodeLensAsync>d__4.MoveNext()

Seems like maybe we need a centralized and better form of file URI handling methods? Or if we already have them, we need to use them.

[rkeithhill]

So the path too long is correct in some cases - like this:

gitlens-git:c%3A%5CUsers%5CKeith%5CGitHub%5Cdahlbyk%5Cposh-git%5Csrc%5CPoshGitTypes%3A841eb456.ps1?%
7B%22fileName%22%3A%22src%2FPoshGitTypes.ps1%22%2C%22repoPath%22%3A%22c%3A%2FUsers%2FKeith%2FGitHub%2Fdahlbyk%2Fposh-git
%22%2C%22sha%22%3A%22841eb456e286564049d244cfb5241873f6b60a00%22%7D

That is 287 chars long which System.IO.Path.GetFullPath() chokes on.

[rkeithhill]

What is disturbing is that on PS Core on Windows, I don't have this problem:

03-24 01:26:29 1> $longPath = 'gitlens-git:c%3A%5CUsers%5CKeith%5CGitHub%5Cdahlbyk%5Cposh-git%5Csrc%5CPoshGitTypes%3A841eb456.ps1?%7B%22fileName%22%3A%22src%2FPoshGitTypes.ps1%22%2C%22repoPath%22%3A%22c%3A%2FUsers%2FKeith%2FGitHub%2Fdahlbyk%2Fposh-git%22%2C%22sha%22%3A%22841eb456e286564049d244cfb5241873f6b60a00%22%7D'
~
03-24 01:26:34 2> [io.path]::GetFullPath($longPath)
Exception calling "GetFullPath" with "1" argument(s): "The given path's format is not supported."
At line:1 char:1
+ [io.path]::GetFullPath($longPath)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : NotSupportedException

That is the expected exception.

Now in Windows PowerShell 5.1 on the same system - Windows 10 1709 with long paths enabled, we get a PathTooLongException:

03-24 00:20:11 25> $longPath = 'gitlens-git:c%3A%5CUsers%5CKeith%5CGitHub%5Cdahlbyk%5Cposh-git%5Csrc%5CPoshGitTypes%3A84
1eb456.ps1?%7B%22fileName%22%3A%22src%2FPoshGitTypes.ps1%22%2C%22repoPath%22%3A%22c%3A%2FUsers%2FKeith%2FGitHub%2Fdahlby
k%2Fposh-git%22%2C%22sha%22%3A%22841eb456e286564049d244cfb5241873f6b60a00%22%7D'
~
03-24 00:40:28 26> [io.path]::GetFullPath($longPath)
Exception calling "GetFullPath" with "1" argument(s): "The specified path, file name, or both are too long. The fully
qualified file name must be less than 260 characters, and the directory name must be less than 248 characters."
At line:1 char:1
+ [io.path]::GetFullPath($longPath)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : PathTooLongException

I'm puzzled. Long path support was added to .NET 4.6.2, this should be working in Windows PowerShell. Hmm...

[rkeithhill]

OK, I think I have a fix for this. PR coming soon.