A project can become un-openable if you create the same example twice

[hahn-kev]

Related to sillsdev/liblcm#365

Describe the bug
Working on tasks in the frontend I ran into this issue, it should be prevented in the backend.

var entryId = ...;
var senseId = ...;
var example = new ExampleSentence {Id = Guid.NewGuid()};
api.CreateExampleSentence(entryId, senseId, example);
api.CreateExampleSentence(entryId, senseId, example);

Expected behavior
The second call should fail with an error.

Note

This issue was seen specifically on a FWData project

[rmunn]

Isn't there already code to prevent duplicates being created for some other types? Semantic domains or complex form types or the like? I remember seeing it but I couldn't find it just now.

[rmunn]

Found the code I was thinking of:

languageforge-lexbox/backend/FwLite/LcmCrdt/Changes/AddSemanticDomainChange.cs

Lines 12 to 17 in 2a4ea85

	public override async ValueTask ApplyChange(Sense entity, IChangeContext context)
	{
	if (entity.SemanticDomains.Any(s => s.Id == SemanticDomain.Id)) return;
	if (await context.IsObjectDeleted(SemanticDomain.Id)) return;
	entity.SemanticDomains.Add(SemanticDomain);
	}

[hahn-kev]

That's for harmony, this is a FWData issue

[myieye]

It's also possible to create duplicate parts of speech in FwData.
For some reason that only became noticeable in #2084.

The issue description suggests we should throw an error, but the CRDT API currently handles these cases by doing nothing and returning the current instance. It seems favorable to make both APIs work the same. I'm not quite sure what's best.

[rmunn]

From discussion with @myieye - the behavior of our CRDT API and FW API should match: when trying to create an entry with a Guid that already exists, both APIs should either throw an exception or do nothing. We should also look at what liblcm would do in this situation.

[myieye]

I've realized that it might be silly forcing the fwdata API to algin with the CRDT API.

We have to anticipate the CRDT API being asked to create the same object multiple times and handle that gracefully.
At least one reason for that is that exceptions thrown in the fw-headless sync pipeline often result in duplicate sync work (i.e. when the sync is retriggered it repeats some of the work it's already done, because we only update our JSON snapshot after a complete successful sync). I don't see that changing anytime soon. So, if we want the APIs to align, that'd be the way to go.

But:

1. Arguably that "forgiving-ness" is just the nature of a CRDT data model and so the fwdata implementation shouldn't be forced to do the same thing
2. Matching would be more work and code with very little added value. The related liblcm issue (Objects can be created with duplicate Guids which breaks the project liblcm#365) would mean that LibLCM checks for duplicates for us and throws. If we wanted to not throw, then we'd have to decide, do we: (a) catch those exceptions and then read and return the existing object or (b) check for duplicates before trying to create (essentially duplicating the LibLCM code we want to add).

I think it's probably fine if we just let LibLCM exceptions propagate. Trying to create a duplicate in fwdata is an exceptional situation i.e. we do not anticipate any of our code trying to do so.

[rmunn]

The liblcm PR throwing an exception for duplicate GUIDs has now been released in NuGet package version 11.0.0-beta0158 of SIL.LCModel. So when we want to incorporate that behavior into FW Lite, we can upgrade to at least 11.0.0-beta0158.