I ran the rebuild script over one of the bugged items, and this correctly fixed the entries in the new store.

🎉 not-surprising yet great news :)

We moved to new store to up to Q1000. We wait for a while and move to a higher limit later

We haven't experience any failures in production.. although it might be because we didn't yet introduce any breaking changes in CSR compared to SSR yet.

Let's remove catching DBError from DatabaseItemTermStore#storeTerms and DatabasePropertyTermStore#storeTerms separately, as they don't really provide that much valuable info in the error on top of the DBError anyway

First patch is ready for review again

@Lea_Lacroix_WMDE this should be solved. Anything else to look at from your side before we resolve?

Waiting on T236681: SqlEntityInfoBuilder reads and writes from the old term store regardless of the config as caching entity info stuff might solve this problem

True. Option 1 is the status quo, and since those race-conditions are quite rare to begin with, and the point made by @Lucas_Werkmeister_WMDE about this validation not being a strict integrity check (@Lydia_Pintscher please correct us if we are making wrong assumptions here) sounds reasonable, I will continue with option 1 for now.

For the new store, we are saving terms in a deferred update. This makes uniqueness checks:
a) if done during request, they might not catch possible collisions with values that are in deferred updates at the moment but haven't been written to db yet.
b) if done as part of the deferred update, they don't have the chance to report back collisions to the user.

https://tools.wmflabs.org/versions/
We have wmf.5 in production now. This one is tagged for wmf.8. is that going to be the branch for this week's train?

No sure how catching DBError could lead to these exceptions yet. I just removed the only place where we do that (mistakenly apparently) in a sub-task, but cannot think of a way to test that it does really solve this issue.

first patch ready for review again .. left some comments where I'd love to have a second (or more) thought

Woohoo finally this can be tested on beta

I'm doing some cleanup work on first patch now

First patch reworked and ready for peer review again

@Hanna_Petruschat_WMDE @Jan_Dittrich
The behavior described in AC should be available fully in beta. Please have a look and test for any problems that fall into not fulfilling the AC of this task. Once you approve it, we can plan for shipping it to production on next train.

first patch for collision detector interfance+implementations is up for review

Moving back to To Do to cover the other bit (the unchecked Database Transactions documentation for other possible optimizations).

Per @Ladsgroup manual testing, there doesn't seem, number of writes per edit seem to be (near-)optimal .. marking that bit with a check.

In T220696#5613058, @Pintoch wrote:

Here is a diff where one of the new fallback summaries failed to be translated to a human-readable form: https://www.wikidata.org/w/index.php?title=Property:P571&diff=1040450905&oldid=1038877052

After talking to @Lydia_Pintscher , we decided to go with a simpler version of the shortend version as suggested in the last comment. Task and parent Task descriptions will updated accordingly.

Another possible improvement could be to reorder the functions alphabetically, not sure if that's a commonly desired thing so I'll leave if for someone else to pick that up :)

Looks great! Resolving this as the original missing functions has been covered.