scalar quit unexpectedly on Mac

[riggtravis]

I'm not able to attach a screenshot, but here's the gist of it, every few minutes I get a popup informing me that scalar has quit unexpectedly. Here's some information about my project structure:

Our team has 100 repositories, many of them old, even more of them with abandoned branches. I suspect that Scalar is getting overwhelmed but I don't have time right now to investigate further. I'm hoping this evening to dig into things and try to find the problem.

[derrickstolee]

Could you run scalar diagnose in one of your registered repositories, then attach the .zip file to this issue? Alternatively, you could try sending it to scalarsupport@service.microsoft.com. Thanks!

[derrickstolee]

You can also run scalar pause 24 to stop maintenance for 24 hours, which should stop the popups. Running scalar unregister in the repositories will also help until we can identify and release a fix.

[riggtravis]

Yes I ran scalar pause in all the repos, so I could continue with my workday. I'll try to get a diagnose file uploaded.

[riggtravis]

Collecting diagnostic info into temp folder /Users/$USER_NAME/workspace/$REPOSITORY/.scalarDiagnostics/scalar_20200219_175012

scalar version 20.01.165.7
git version 2.25.0.vfs.1.1
/usr/local/bin/git

Enlistment root: /Users/$USER_NAME/workspace/$REPOSITORY
Unhandled exception. Scalar.Common.InvalidRepoException: Error while reading 'gvfs.cache-server' from config: fatal: --local can only be used inside a git repository

   at Scalar.Common.Http.CacheServerResolver.GetValueFromConfig(GitProcess git, String configName, Boolean localOnly) in /Users/runner/runners/2.164.6/work/1/s/Scalar.Common/Http/CacheServerResolver.cs:line 143
   at Scalar.Common.Http.CacheServerResolver.GetUrlFromConfig(Enlistment enlistment) in /Users/runner/runners/2.164.6/work/1/s/Scalar.Common/Http/CacheServerResolver.cs:line 31
   at Scalar.Common.Http.CacheServerResolver.GetCacheServerFromConfig(Enlistment enlistment) in /Users/runner/runners/2.164.6/work/1/s/Scalar.Common/Http/CacheServerResolver.cs:line 23
   at Scalar.CommandLine.DiagnoseVerb.Execute(ScalarEnlistment enlistment) in /Users/runner/runners/2.164.6/work/1/s/Scalar/CommandLine/DiagnoseVerb.cs:line 68
   at Scalar.CommandLine.ScalarVerb.ForExistingEnlistment.Execute(GitAuthentication authentication) in /Users/runner/runners/2.164.6/work/1/s/Scalar/CommandLine/ScalarVerb.cs:line 615
   at Scalar.CommandLine.ScalarVerb.ForExistingEnlistment.Execute() in /Users/runner/runners/2.164.6/work/1/s/Scalar/CommandLine/ScalarVerb.cs:line 605
   at Scalar.Program.<>c.<Main>b__0_4(ScalarVerb verb) in /Users/runner/runners/2.164.6/work/1/s/Scalar/Program.cs:line 94
   at CommandLine.ParserResultExtensions.WithParsed[T](ParserResult`1 result, Action`1 action)
   at Scalar.Program.Main(String[] args) in /Users/runner/runners/2.164.6/work/1/s/Scalar/Program.cs:line 51
fish: 'scalar diagnose' terminated by signal SIGABRT (Abort)

No zip file generated. Also the .scalarDiagnostics/scalar_20200219_175012/diagnostics.log file is empty of content

[riggtravis]

Just noticed the line about fish. I'm going to try rerunning from bash.

Only changes is the final line is Abort trap: 6 now

[derrickstolee]

Is your repository a worktree, by chance? The way you can tell is if the .git path in your repo is a directory or a file.

[riggtravis]

.git is a directory in my case

[derrickstolee]

And if you run git config --local in /Users/$USER_NAME/workspace/$REPOSITORY/, I assume that your Git command works? That should be what Scalar is executing and expecting to succeed.

In the meantime, I will be sure to harden our checks around this to not fail like this when getting this error.

[riggtravis]

Yes. Git config behaves as expected when using the--local flag. Just double checked to be sure

[matzuk]

@riggtravis @derrickstolee
Hi guys!
In summary, is this issue resolved or not?

[derrickstolee]

@matzuk I would say it is not resolved.

1. We do not know the root cause, really. We will catch and log this exception but we don’t know how we got into this state. Outside of the initial report, we are unable to reproduce the issue.

2. We have not released a new version that includes the new exception handling. We will cut a new release this week, and then we can see if this resolves the issue or helps us diagnose the problem.

Alternatively, someone with this issue could build the code from master and install that dev build to see if we can learn anything from that, but I hesitate to ask anyone to work so hard when we can just wait for the release.

[derrickstolee]

I think this may be resolved by e1b2a97 as part of #353. Let's revisit this after the next release (hopefully next week).

[derrickstolee]

I'm closing this issue as we think it is resolved now, but feel free to reopen if you have this issue on a recent release.