[14:51:31] duesen: You around? I'm trying to work out how I can ensure that MultiContentSave is called after other edit's secondary updates have happened, or elsewise what the best method for stopping saves to ensure uniqueness is for content derivatives. Context is https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikiLambda/+/625916 [15:04:21] James_F: hey [15:04:51] that problem sounds familiar.... [15:04:59] Indeed. :-( [15:06:07] The answer to your question will depend on how safe this has to be. Do to be *sure* that it'S always bsolutely unique? Dealing with race conditions is going to be tricky... [15:06:34] I think for wikidata we tried to be strict and do the check within the primary db transaction, but that led to problems with lock contention. [15:11:38] The best I can come up with that doesn't require the check to be performed within the critical trx is: check up front, e.g. in the MultiContentSave hook. Then later, when trying to insert the secondary data, detect any conflicts due to concurrent edits. If such a conflict is detected, shedule a job that reverts the edit. [15:12:01] That would work, but would be inivisble to the user. You'd have to somehow notify them. [15:12:42] ...notifiy them after thir edit has apparently gone through and they have received a response from the server. [15:13:24] The alternative is to just tollerate conflicts, and periodically generate a work list for cleanup. [15:14:00] Hmm. [15:14:11] Or just silently drop conflicts on writing them to the index? [15:15:12] But the problem is that I can't even get my unit test to work, because the edit we're conflicting with happens, but the secondary update hasn't yet by the time my unit test runs. [15:18:40] In unit tests, deferred updates should run inline... you can call DeferredUpdates::doUpdates() to force them [15:19:15] Silently dropping conflicts makes it impossible to clean up the conflicting items. You could have another table that records them [15:19:57] I think the system reverting human edits is probably not a great idea, though. [15:21:47] yes, i agree. The cleanup should probably be manual, not automatic. [15:21:58] Special:ZObjectsWithConflictingLabels [15:22:06] Yeah, will stash them into a FIXME page or something. [15:22:09] * James_F sighs. [15:22:21] Most of the code doesn't exist and I'm already creating product debt. ;-( [15:22:35] that's how it goes ;) [15:22:54] But with all this said, I don't know why your unit test wouldn't be working [15:24:59] `DeferredUpdates::doUpdates();` doesn't fix it, FWIW. :-( [15:25:30] That sounds broken. Secondary updates should run after the edit. Something is getting lost somewhere... [15:25:32] Oh, never mind me. [15:25:51] Just a catastrophically slow system.