Handle Mercurial.UnrelatedRepositoryErrorException automatically by discarding LF repo and re-cloning

[megahirt]

An unrelated repository exception can occur when the corresponding Language Depot repo is replaced with a new one by a Flex support person. This is usually done to reduce the size of a repo (drop old revisions) or to restore the project to a previously known good state.

When LFMerge encounters a UnrelatedRepositoryErrorException in the process of syncing it should:

1. delete the local copy of the repo /var/lib/languageforge/lexicon/sendreceive/webwork/projectid
2. re-clone the project
3. carry on syncing

Some unknowns that we need to test:

• can our current code recover from a missing repo or deleted repo on the LF side? If so, then implementing this card is probably mostly done.
• does the data continue to sync as expected after the re-clone operation? Or does it take an extra sync to get the data synced?
• are the symlinks recreated between the sendreceive/webwork folder and the project folder in src/assets/lexicon?

Original stacktrace:

Chorus.VcsDrivers.Mercurial.UnrelatedRepositoryErrorException: The repository(a.k.a 'project' or 'collection') that you tried to synchronize with has the same name as yours, but it does not have the same heritage, so it cannot be synchronized. In order to Send/Receive projects, you have to start with a single project/collection, then copy that around. Don't feel bad if this is confusing, just ask for some technical help.
  at Chorus.VcsDrivers.Mercurial.HgRepository.PullFromTarget (System.String targetLabel, System.String targetUri) [0x00106] in <d98940b1597342908bfb88b257fca6f5>:0
  at Chorus.VcsDrivers.Mercurial.HgNormalTransport.Pull () [0x00000] in <d98940b1597342908bfb88b257fca6f5>:0
  at Chorus.VcsDrivers.Mercurial.HgRepository.Pull (Chorus.VcsDrivers.RepositoryAddress source, System.String targetUri) [0x00050] in <d98940b1597342908bfb88b257fca6f5>:0
  at LfMergeBridge.LanguageForgeSendReceiveActionHandler.LibTriboroughBridgeChorusPlugin.Infrastructure.IBridgeActionTypeHandler.StartWorking (SIL.Progress.IProgress progress, System.Collections.Generic.Dictionary`2[TKey,TValue] options, System.String& somethingForClient) [0x001cd] in <dbee31384bce49b1bd2ffaab93484008>:0
  at LfMergeBridge.LfMergeBridge.Execute (System.String actionType, SIL.Progress.IProgress progress, System.Collections.Generic.Dictionary`2[TKey,TValue] options, System.String& somethingForClient) [0x000df] in <dbee31384bce49b1bd2ffaab93484008>:0
  at LfMerge.Core.Actions.SynchronizeAction.DoRun (LfMerge.Core.ILfProject project) [0x0013c] in /build/lfmerge-7000072-9dfRZq/lfmerge-7000072-2.0.90.52/src/LfMerge.Core/Actions/SynchronizeAction.cs:98
  at LfMerge.Core.Actions.Action.Run (LfMerge.Core.ILfProject project) [0x0010d] in /build/lfmerge-7000072-9dfRZq/lfmerge-7000072-2.0.90.52/src/LfMerge.Core/Actions/Action.cs:142
  at LfMerge.Program.RunAction (System.String projectCode, LfMerge.Core.Actions.ActionNames currentAction) [0x000ed] in /build/lfmerge-7000072-9dfRZq/lfmerge-7000072-2.0.90.52/src/LfMerge/Program.cs:128 

I am trying to think how this Exception could occur. More investigation is needed to understand how this error can occur in LF.

[josephmyers]

Stacktrace is busted, but it was easy to find the line in Bridge that caused the error (line 94 in LanguageForgeSendReceiveActionHandler on develop). As for the actual error, it seems somewhat self-explanatory and comes from here, starting around line 321 in master.

[josephmyers]

So Chris explained this for me. The LF cache has become invalidated (likely due to operations on the Language Depot side), and we need to clear the cache and pull things fresh.

[megahirt]

Yes. More specifically, the Language Depo repo has been "reset" by tech support i.e. folder deleted and new repo created in its place, followed by a FLEx "push" to repopulate the repo. Whenever we get an "unrelated repo" exception in LFMerge, we should simply delete our repo copy and then clone a fresh one from LD, then carry on the original operation.