[00:17:25] Krinkle, did you see Lucas grumping about the RL namespace merges at https://phabricator.wikimedia.org/T308718#7955786 ? [00:24:06] also, I tried SqlBagOStuff composition split -- the one difficulty was waitForReplication() and its configuration busyCallbacks and syncTimeout [00:24:47] but I followed the trail in git blame and phabricator, and it seems the whole thing will not be used in production [00:30:09] in particular https://gerrit.wikimedia.org/r/c/mediawiki/core/+/664415 "Remove WRITE_SYNC flag from ChronologyProtector since the current plan is to simply use a datacenter-local storage cluster." [00:30:14] TimStarling: yeah, I traced this as well not so long ago, my entry was the related code for it lower down in ChronologyProtector and further up in MediaWiki.php. I haven't fully confirmed but it seemed very likely that with the current direciton we'd indeed need none of that stack. [00:31:04] the context is that ChronologyProtector was originally going to do WRITE_SYNC in such a way that it actually only writes local-dc, then we do the majority of skin rendering logic, and then waitConditionLoop. [00:31:20] This is a pattern also found in Captcha/SessionStore I believe. [00:32:17] nothing calls addBusyCallback() since the ChronologyProtector call was removed, so I was thinking of turning that into a hard-deprecated stub, i.e. it won't fail but won't actually register a callback [00:32:49] because there was no guarantee in the interface that busy callbacks would actually be called [00:33:19] I'd like Aaron to confirm in case we missed a use case that we still need to add, but overall I'd be happy to see the MeidaWiki call stack simplified and the bago code simplified if we don't need it indeed. [00:35:12] I belive this in turn was written for the edge case of where ChronologyProtector could not set a cookie or query parameter for the next request, e.g. not same origin, and not cross-origin witin the same DC (e.g. GET redirect to loginwiki, where the sticky DC cookie would not apply), and so for that case I believe the intention was to wait synchronously upfront before kicking off the redirect chain. [00:35:46] anyway, we don't need that now.