ArthurTaylor added a comment.
In some further investigation today, I was able to reproduce at least part of
the issue on my local setup by doing the following, with
`$wgWBClientSettings['entityUsageModifierLimits']['C'] = 2`
- Start, as expected, with generic C statement in database - in this case I
have 3 statements referring to the same item, against a limit of 2.
- Remove the third statement, to bring us under the limit.
- onParserCacheSaveComplete fires, followed by doLinksUpdateComplete
- 2 Specific C's appear in the database, and a job is queued to add 2 usages
- Add the third statement back again, to take us over the limit
- onParserCacheSaveComplete fires, followed by doLinksUpdateComplete
- 1 generic C is in the database, and a job is queued to add a generic C.
- Run the jobs
- The first jobs adds the 2 specific C statements to the database
- The second job would add the generic statement, but it is already present
Subsequently making a null edit clears the issue out and leaves me with the
generic C in my usages table.
I dug around to see where the different functions were getting triggered, and
everything is happening via DeferredUpdates (besides the job runs themselves).
`onLinksUpdateComplete` is scheduled as a deferred `AutoCommitUpdate` in
`LinksUpdate.php`, and `onParserCacheSaveComplete` is triggered by the
`doModify` function of `PageUpdater.php` It's not clear to me that the order of
the execution of the DeferredUpdates is 100% deterministic (based on the log
messages captured above (T255706#9421575
<https://phabricator.wikimedia.org/T255706#9421575>), it appears that at least
on one machine the jobs run in the other order to the way they run on my
machine.
The patch I've drafted above changes the semantics of `addUsedEntities` to
make it aware of statement grouping - so that it won't add a `Q1#C.P12` where a
`Q1#C` is present, and will remove all `Q1#C.PX` statements when adding a
`Q1#C` statement. My hope is that this makes the tasks more serialisable / less
order-dependent. But I want to confer with @Michael and @Lucas_Werkmeister_WMDE
about whether the approach makes sense before moving forward.
TASK DETAIL
https://phabricator.wikimedia.org/T255706
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: ArthurTaylor
Cc: ArthurTaylor, hoo, Lucas_Werkmeister_WMDE, ItamarWMDE, Ladsgroup, Krinkle,
eprodromou, aaron, Michael, Aklapper, thcipriani, Danny_Benjafield_WMDE,
Isabelladantes1983, Themindcoder, Adamm71, Jersione, Hellket777, LisafBia6531,
Astuthiodit_1, 786, Biggs657, karapayneWMDE, Invadibot, maantietaja, Juan90264,
Alter-paule, Beast1978, Un1tY, Akuckartz, Hook696, darthmon_wmde, Rosalie_WMDE,
Kent7301, joker88john, CucyNoiD, Nandana, Gaboe420, Giuliamocci, Cpaulf30,
Lahi, Gq86, Af420, Bsandipan, GoranSMilovanovic, QZanden, LawExplorer,
Lewizho99, Maathavan, _jensen, rosalieper, Neuronton, Scott_WUaS, Verdy_p,
Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g
_______________________________________________
Wikidata-bugs mailing list -- [email protected]
To unsubscribe send an email to [email protected]
