Omnisharp server errors on Fugitive Gdiff

[jmzagorski]

Running Gdiff on a csharp file creates a run time error with omnisharp-rosyln 1.32.2. Viewing the :message command I see

CONNECTION: <urlopen error timed out>
channel 2 open: 'System.ArgumentException: The path must be absolute.'
channel 2 open: 'Parameter name: root'
channel 2 open: '   at Microsoft.Extensions.FileProviders.PhysicalFileProvider..ctor(String root, PhysicalFilesWatcher physicalFilesWatcher, ExclusionFilters filters)'
channel 2 open: '   at OmniSharp.ConfigurationBuilder.Build()'
channel 2 open: '   at OmniSharp.Http.Startup..ctor(IOmniSharpEnvironment environment, IEventEmitter eventEmitter, ISharedTextWriter writer)'
channel 2 open: '--- End of stack trace from previous location where exception was thrown ---'
channel 2 open: '   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()'
channel 2 open: '   at Microsoft.Extensions.DependencyInjection.ActivatorUtilities.ConstructorMatcher.CreateInstance(IServiceProvider provider)'
channel 2 open: '   at Microsoft.AspNetCore.Hosting.Internal.StartupLoader.LoadMethods(IServiceProvider hostingServiceProvider, Type startupType, String environmentName)'
channel 2 open: '   at Microsoft.AspNetCore.Hosting.WebHostBuilderExtensions.<>c__DisplayClass1_0.<UseStartup>b__1(IServiceProvider sp)'
channel 2 open: '   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitScoped(ScopedCallSite scopedCallSite, ServiceProviderEngineScope scope)'
channel 2 open: '   at Microsoft.Extensions.DependencyInjection.ServiceLookup.DynamicServiceProviderEngine.<>c__DisplayClass1_0.<RealizeService>b__0(ServiceProviderEngineScope scope)'
channel 2 open: '   at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetService[T](IServiceProvider provider)'
channel 2 open: '   at Microsoft.AspNetCore.Hosting.Internal.WebHost.EnsureStartup()'
channel 2 open: '   at Microsoft.AspNetCore.Hosting.Internal.WebHost.EnsureApplicationServices()'
channel 2 open: '   at Microsoft.AspNetCore.Hosting.Internal.WebHost.Initialize()'
channel 2 open: '   at Microsoft.AspNetCore.Hosting.WebHostBuilder.Build()'
channel 2 open: '   at OmniSharp.Http.Host.Start()'
channel 2 open: '   at OmniSharp.Http.Driver.Program.<>c__DisplayClass0_1.<Main>b__1()'
channel 2 open: '   at OmniSharp.HostHelpers.Start(Func`1 action)'
channel 2 open: ''
channel 2 open: 'Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object.'
channel 2 open: '   at OmniSharp.Utilities.PhysicalFileProviderExtensions.PhysicalFileProviderWrapper.DisposeCore(Boolean disposing)'
channel 2 open: '   at OmniSharp.Utilities.DisposableObject.Finalize()'
CONNECTION: <urlopen error timed out>

Not sure if you could do anything in this lib since the error looks like it is in the omnisharp code, but thought I should bring it to your attention. Omnisharp still runs fine after that, but shows the runtime error dialog every time.

Let me know if I need to provide additional information.

[nickspoons]

Thanks for reporting this. There was already an OmniSharp#FugitiveCheck() function, but it needed be used a bit more liberally. I could re-create the issue and it appears to be fixed with this commit.

[jmzagorski]

@nickspoons I see this error again on the most current version of this library. Are you able to confirm this?

[nickspoons]

@jmzagorski yes I can confirm it after upgrading to the latest version of fugitive. I know that tpope has been doing a big rewrite and something seems to have changed - I'm not quite sure what it is yet though, as the fugitive buffers are still called fugitive:///... which is what our checks looks for. More investigation required

[nickspoons]

Hmm. No on second thoughts I think the fugitive upgrade was a red herring.

I can reproduce an error by opening a .cs file and running :Gdiff before the server has finished loading. After which it is the calls to /highlight which are erroring. Linting the buffer with ALE at this point also shows lots of duplicate declaration errors, which I believe is an OmniSharp-roslyn issue which has been fixed in later versions. It's quite possible that this is also causing the highlighting issue.

Do you have g:OmniSharp_highlight_types = 1 @jmzagorski? What is your step-by-step workflow to trigger the error?

[jmzagorski]

I have g:OmniSharp_highlight_types = 0. I can produce the error with two workflows.

1. Run vim at the solution directory level
2. Gstatus
3. Select a cs file
4. dv

or

1. Run vim at the solution directory level
2. find <chsharp file> to open it
3. Gdiff

I have this plugin loaded on the FileType event with packadd since it is in my opt directory. Before running Gdiff i made sure ALE was working. Hopefully that helps. Let me know if I can do anything else to help.

[nickspoons]

Thanks @jmzagorski.

Would you please try the following and see if it helps here:

1. open vim and :find <c# file>
2. wait for 1 minute to ensure the roslyn server has started
3. :find <another c# file>
4. <C-6> to switch back to the previous file
5. Notice if any errors have occurred at this stage ... anything in :messages?
6. :Gdiff

For me, letting the server start properly removes all errors. I'm not having much success detecting the completely loaded server from vim though.

[nickspoons]

Oh ... and which OS are you on, and with which g:OmniSharp_... settings?

[jmzagorski]

On windows 10 enterprise build 17763: At step 5 i have this error, which I always get and just ignore since the server seems to be working with ALE: Error Connection: <urlopen error [Errno 10061] No Connection could be made because the target machine actively refused it>.

WSL Ubuntu 18.04.2 was a different story. I thought I received the same error on Gdiff, but i retested it twice and no Omnisharp dialog error. Although the error message at step 5 was CONNECTION: <urlopen error [Errno 111] Connection refused, but ALE still works.

Global omnisharp variables using the windows command prompt: (i manually substituted $USERNAME below:

OmniSharp_loglevel                  warning
OmniSharp_server_type               roslyn
OmniSharp_highlight_types           #0
OmniSharp_sln_list_index            #-1
OmniSharp_selector_ui
OmniSharp_sln_list_name
Omnisharp_stop_server               #1
OmniSharp_want_snippet              #1
OmniSharp_quickFixLength            #60
OmniSharp_timeout                   #5
OmniSharp_start_server              #1
OmniSharp_autoselect_existing_sln   #1
OmniSharp_python_path               C:\Users\$USERNAME\vimfiles\pack\minpac\opt\omnisharp-vim\python
OmniSharp_typeLookupInPreview       #0
OmniSharp_server_ports              {'C:\Users\$USERNAME\Source\ItemMaster\ItemMaster.sln':            55264}
OmniSharp_CursorHoldSyntaxCheck     #0
OmniSharp_translate_cygwin_wsl      #0
OmniSharp_prefer_global_sln         #0
OmniSharp_server_use_mono           #0
OmniSharp_ctrlp_extensions_added    #1
OmniSharp_py_err                    {}
OmniSharp_start_without_solution    #0
OmniSharp_server_config_name        omnisharp.json
OmniSharp_BufWritePreSyntaxCheck    #1
OmniSharp_proc_debug                #0
OmniSharp_open_quickfix             #1
OmniSharp_loaded                    #1

[nickspoons]

Do you also still get the CONNECTION: <urlopen error timed out> from the original issue?

Can you use other OmniSharp functionality than ALE? i.e. :OmniSharpGotoDefinition, :OmniSharpFindUsages etc.?

Do the errors you're describing only occur at the start of the session, and then not again, or are there errors happing repeatedly?

I'm starting to think that none of this has anything to do with the original issue and fugitive any more. There's an issue with the server I think, where it responds successfully (and quickly) to our polling endpoint, but loads some functionality lazily. Which means that some things take quite a while the first time, and sometimes they are not handled gracefully on the OmniSharp-roslyn side. For these issues you can sometimes just extend the g:OmniSharp_timeout even more, since it's generally just the first occurrance which is slow. The errors I got earlier on a big project (the OmniSharp-roslyn source) went away when I let g:OmniSharp_timeout = 20.

But as I say I can't quite tell if this is what you're experiencing, or something else.

[jmzagorski]

I am not getting the timeout error, but I think I figured out why i am getting that other error prior to running Gdiff

I recently switched to the vim package manager and have this library in the opt folder. I have an ftplugin file for cs file types that runs packadd if it is not in the runtime path already. An odd thing I noticed with packadd is that i need to refresh the buffer with :e for file type packages before it recognizes the package.

When I run through your steps again (with a timeout of 20s and then 60s) i do not receive any errors before running Gdiff when typing :e<CR> when i get into the buffer, but it still errors on Gdiff

CONNECTION: <urlopen error [Errno 10061] No connection could be made because the target machine actively refused it>
channel 13 open: 'System.ArgumentException: The path must be absolute.'
channel 13 open: 'Parameter name: root'
channel 13 open: '   at Microsoft.Extensions.FileProviders.PhysicalFileProvider..ctor(String root, PhysicalFilesWatcher physicalFilesWatcher, ExclusionFilters filters)'
channel 13 open: '   at OmniSharp.ConfigurationBuilder.Build()'
channel 13 open: '   at OmniSharp.Http.Startup..ctor(IOmniSharpEnvironment environment, IEventEmitter eventEmitter, ISharedTextWriter writer)'
channel 13 open: '--- End of stack trace from previous location where exception was thrown ---'
channel 13 open: '   at System.Runtime.ExceptionServices.ExceptionDispatchInfo.Throw()'
channel 13 open: '   at Microsoft.Extensions.DependencyInjection.ActivatorUtilities.ConstructorMatcher.CreateInstance(IServiceProvider provider)'
channel 13 open: '   at Microsoft.AspNetCore.Hosting.Internal.StartupLoader.LoadMethods(IServiceProvider hostingServiceProvider, Type startupType, String environmentName)'
channel 13 open: '   at Microsoft.AspNetCore.Hosting.WebHostBuilderExtensions.<>c__DisplayClass1_0.<UseStartup>b__1(IServiceProvider sp)'
channel 13 open: '   at Microsoft.Extensions.DependencyInjection.ServiceLookup.CallSiteRuntimeResolver.VisitScoped(ScopedCallSite scopedCallSite, ServiceProviderEngineScope scope)'
channel 13 open: '   at Microsoft.Extensions.DependencyInjection.ServiceLookup.DynamicServiceProviderEngine.<>c__DisplayClass1_0.<RealizeService>b__0(ServiceProviderEngineScope scope)'
channel 13 open: '   at Microsoft.Extensions.DependencyInjection.ServiceProviderServiceExtensions.GetService[T](IServiceProvider provider)'
channel 13 open: '   at Microsoft.AspNetCore.Hosting.Internal.WebHost.EnsureStartup()'
channel 13 open: '   at Microsoft.AspNetCore.Hosting.Internal.WebHost.EnsureApplicationServices()'
channel 13 open: '   at Microsoft.AspNetCore.Hosting.Internal.WebHost.Initialize()'
channel 13 open: '   at Microsoft.AspNetCore.Hosting.WebHostBuilder.Build()'
channel 13 open: '   at OmniSharp.Http.Host.Start()'
channel 13 open: '   at OmniSharp.Http.Driver.Program.<>c__DisplayClass0_1.<Main>b__1()'
channel 13 open: '   at OmniSharp.HostHelpers.Start(Func`1 action)'
channel 13 open: ''
channel 13 open: 'Unhandled Exception: System.NullReferenceException: Object reference not set to an instance of an object.'
channel 13 open: '   at OmniSharp.Utilities.PhysicalFileProviderExtensions.PhysicalFileProviderWrapper.DisposeCore(Boolean disposing)'
channel 13 open: '   at OmniSharp.Utilities.DisposableObject.Finalize()'
CONNECTION: <urlopen error [Errno 10061] No connection could be made because the target machine actively refused it>

[jmzagorski]

Forgot to mention that the OmniSharp commands are available and work only after i run :e, because of the packadd issue i mentioned above

[nickspoons]

OK so it is still the original error.

I can reproduce the System.ArgumentException: The path must be absolute. part by removing some fugitive checks in my plugin. I don't really know why they're not catching fugitive buffers for you. My errors don't have the CONNECTION: <urlopen error ... bit but that seems to be python - are you by chance using python2? I'm using python3.

This is a bit of a long shot but would you mind trying the branch I'm currently working on here? As well as the highlighting stuff which won't affect you, I've made some adjustments to when and how the fugitive check works.

[nickspoons]

Actually, before trying a whole different branch of a fork ... try changing just this line:

return &buftype ==# 'nofile' || match(expand('<afile>:p'), 'fugitive:///' ) == 0

to

return &buftype ==# 'nofile' || match(expand('%:p'), 'fugitive:///' ) == 0

[jmzagorski]

My vim is built with python2 and python3. I tried what you said, which is really should have done to begin with and here is what i found:

I noticed the fugitive diff buffer is fugitive:\\ and my guess is that match does not handled the slash conversion for windows?

[nickspoons]

Hmm, perhaps this is due to the fugitive upgrade after all?

Well I've included the Windows-path fugitive-prefix now in the nickspoons/omnisharp-vim highlight-syn-options branch and I am not getting any errors in Windows gvim - can you give it a go? I tried with just modifying the line above but it wasn't enough - the other new safeguards I've included are necessary.

[jmzagorski]

This is working in gvim and vim (command prompt). I do receive that ...actively refused it error while the diff windows are open, but that is not a big deal because everything seems to be working...Thanks!

[nickspoons]

That error is so strange! I can't reproduce it in the highlighting branch any more so I'm going to have trouble doing any more about it.

Anyway I'll merge that branch soon, glad things otherwise are working!

[nickspoons]

Hey do you always get the error when you :Gdiff? What about if you do a diff, close it, open another file and then diff that - does it error again?

[jmzagorski]

Yup, just ran the test at home and work. Wanted to make sure something on our work network was not intervening.