Lucas_Werkmeister_WMDE added a comment.

  In T255706#9512254 <https://phabricator.wikimedia.org/T255706#9512254>, 
@ArthurTaylor wrote:
  
  > I still have a patch 
<https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/987962> that 
we haven't applied that makes the `addUsages` job check for the presence of 
collective `C` statements before adding individual `C` statements. This 
addresses a race which I know is still present and I can reproduce locally, 
that occurs when the number of statements transitions from below the 
`entityUsageModifierLimits` to above.
  
  I would put that patch slightly elsewhere, e.g. in `DataUpdateHookHandler`:
  
    diff --git a/client/includes/Hooks/DataUpdateHookHandler.php 
b/client/includes/Hooks/DataUpdateHookHandler.php
    index 587bea29f5..030ef0b8ff 100644
    --- a/client/includes/Hooks/DataUpdateHookHandler.php
    +++ b/client/includes/Hooks/DataUpdateHookHandler.php
    @@ -188,7 +188,8 @@ public function onParserCacheSaveComplete( 
$parserCache, $parserOutput, $title,
                 // during a GET request.
     
                 $currentUsages = $this->usageLookup->getUsagesForPage( 
$title->getArticleID() );
    -            $newUsages = array_diff_key( $usages, $currentUsages );
    +            $allUsages = $this->usageDeduplicator->deduplicate( 
array_merge( $usages, $currentUsages ) );
    +            $newUsages = array_diff_key( $allUsages, $currentUsages );
                 if ( $newUsages === [] ) {
                     return;
                 }
  
  But it could also make sense in the job itself 
(`AddUsagesForPageJob::run()`). This would probably remove the deadlocks, but 
not (on its own) fix the problem of bad usage tracking in Parsoid. So let’s fix 
the usage tracking first and see if the deadlocks go down.

TASK DETAIL
  https://phabricator.wikimedia.org/T255706

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Lucas_Werkmeister_WMDE
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, KimKelting, 
LawExplorer, Lewizho99, Maathavan, _jensen, rosalieper, Neuronton, Scott_WUaS, 
Verdy_p, Wikidata-bugs, aude, Jdforrester-WMF, Mbch331, Jay8g
_______________________________________________
Wikidata-bugs mailing list -- wikidata-bugs@lists.wikimedia.org
To unsubscribe send an email to wikidata-bugs-le...@lists.wikimedia.org

Reply via email to