[BUG] Highest EntryID not recorded correctly in one corpus (or maybe more?)

[kvesik]

I was attempting to add a sign to the AFTERNOON_v1_ALARM corpus and discovered that the first new sign added does not appear in the corpus list (nor does it appear to get added to the set of signs at the back end either) BUT the second, third, and later signs do.

To reproduce:

1. Open SLP-AA and load the specified corpus (see links below).
2. Click the green plus button to add a new sign.
3. Enter a gloss (at least) and save.
4. Notice that the new sign is not shown in the corpus list, though its summary does appear in the visual summary panel.
5. Click the green plus button to add another new sign.
6. Enter a gloss (at least) and save.
7. Notice that the new sign is shown in the corpus list, as well as in the visual summary panel.

I have only encountered this bug so far with one corpus (though two different versions of that corpus):

• 2023_04_11_AFTERNOON_v1_ALARM_AA_KCH.slpaa
• 2023_04_11_AFTERNOON_v1_ALARM_AA_KCH_YG_KCH.slpaa

Upon closer inspection, it appears that this corpus contains 10 signs, with entry IDs 0001 through 0009, and 0011. Perhaps another sign was originally entered and then deleted? At any rate, the numbering is not the problem. The problem is that the serialized (saved-to-file) version of this corpus has its "higest ID" recorded as 10 instead off 11. So when I attempt to add a new sign, the highest ID is auto-incremented to 11, but the new sign is not added (I assume due to some conflict with there already being a sign with ID 11... though I don't see any errors thrown so ???). But once I go to add a second new sign, the highest ID is auto-incremented to 12, and the sign is successfully added to the corpus, as are any following ones.

I'm not sure whether this is a quirk related to this corpus specifically, or if there was some issue with how signs were being deleted or added at some point (if I create a new corpus now, delete a sign, and save, then reopen and attempt to add a new sign it works as expected). For the time being, we can use a workaround that consists of:

• when loading a new corpus from file, iterate through all the signs and check for the highest ID
• update corpus.highestID if necessary
• continue as usual
• log warning

... But we should also...

• [ ] check if any other corpora have the same issue (just try to add a new sign and see if it works or not, or programmatically check if the highest ID actually = the corpus.highestID)
• [ ] review sign deletion code, sign addition code, and/or changes to either to see if there's a reason that still persists for the highestID for this corpus being saved as 10 even though it was actually 11

[kvesik]

I'm going to merge the workaround from branch 242 into main, so that other users can let me know if it comes up for them. But this issue should remain open.

[stannam]

https://github.com/PhonologicalCorpusTools/SLPAA/blob/6536b39ba8da9038848252d0b74e057866ee3e7b/src/main/python/lexicon/lexicon_classes.py#L435-L438

I think confirmhighestID() should not be called when serializing an empty corpus since there would be no entry IDs.

I'll just go ahead and add a conditional like this.

if len(self) > 0:  # self being Corpus
  self.confirmhighestID("save")
(...)

[kvesik]

closing; does not seem to have persisted into current use