Addshore added a comment.

  I chatted a little with @Krinkle and @daniel and ...
  
  Firstly:
  
  - The `purgeWebCache` correctly triggers a `UpdateHtmlCacheJob` which runs 
quickly and "dirties" the parsercache for the page being dispatched to
  - This leads to cache misses when using a debug line like 
`(MediaWiki\MediaWikiServices::getInstance()->getParserCache())->get(Title::newFromText('Category:Interior
 of Chapelle des Anges de Neunhoffen à Dambach 
(Bas-Rhin)')->toPageRecord(),ParserOptions::newCanonical())->getCacheTime();`
  - A user view will parse the page correctly, and the page property for 
wikibase_item will be visible in the parser output with 
`(MediaWiki\MediaWikiServices::getInstance()->getParserCache())->get(Title::newFromText('Category:Interior
 of Chapelle des Anges de Neunhoffen à Dambach 
(Bas-Rhin)')->toPageRecord(),ParserOptions::newCanonical())->getProperty('wikibase_item');`
  - At this stage the page_prop will not be in the page_props table.
  
  Secondly:
  
  - The `scheduleRefreshLinks` should trigger a `RefreshLinksJob`. (These take 
a little longer to run in most cases)
  - At some unknown time in the future the `page_props` table should be 
populated with the `wikibase_item` page property. (we saw this happen a few 
times)
  - You'd be able to see this in the DB, or using something like 
`PageProps::getInstance()->getProperties([Title::newFromText('Category:Interior 
of Chapelle des Anges de Neunhoffen à Dambach (Bas-Rhin)')],'wikibase_item');`
  
  -----
  
  Now trying to apply this again to the random failures seen in T233520: 
page_props wikibase_item is sometimes not added to client pages when a sitelink 
is added on a repo <https://phabricator.wikimedia.org/T233520> where 
`page_props` is seemingly never populated....
  
  One can make a WikiPageUpdater for a client with:
  
    $services = MediaWiki\MediaWikiServices::getInstance();
    $pu = new \Wikibase\Client\Changes\WikiPageUpdater( 
JobQueueGroup::singleton(), \Wikibase\Client\WikibaseClient::getLogger( 
$services ), $services->getStatsdDataFactory());
  
  And then trigger a web cache job with something like:
  
    $pu->purgeWebCache( [ Title::newFromText('Category:Interior of Chapelle des 
Anges de Neunhoffen à Dambach (Bas-Rhin)') ], 
['rootJobTimestamp'=>wfTimestampNow()], 'update', 'uid:addshore' );
  
  As with the bullet point lists above, we see the cache start missing at this 
point, and a web view will re parse the page.
  
  When trying to do the same with the page for the refreshlinks job, I can do 
the following:
  
    $pu->scheduleRefreshLinks( [ Title::newFromText('Category:Interior of 
Chapelle des Anges de Neunhoffen à Dambach (Bas-Rhin)') ], 
['rootJobTimestamp'=>wfTimestampNow()], 'update', 'uid:addshore' );
  
  In theory this should schedule the job, and no error occurs.
  But in both of these job cases I do not see anything matching the job I 
scheduled in kafka (perhaps I'm looking in the wrong place).
  I waited 10-30 minutes and did not see the `page_props` for a category page 
on commons end up updating. (could be the job was still in the queue?)
  
  I then manually ran the job on the debug server:
  
    (new RefreshLinksJob( Title::newFromText('Category:Interior of Chapelle des 
Anges de Neunhoffen à Dambach (Bas-Rhin)'), 
['rootJobTimestamp'=>wfTimestampNow()] ))->run();
  
  And the page_prop now instantly appears in the page_props table
  
    >>> 
PageProps::getInstance()->getProperties([Title::newFromText('Category:Interior 
of Chapelle des Anges de Neunhoffen à Dambach (Bas-Rhin)')],'wikibase_item');
    => [
         103128055 => "Q106684122",
       ]
  
  
  
  ---------
  
  So either:
  
  1. The call to scheduleRefreshLinks is not actually scheduling a job? and 
thus the page_props table is never being updated?
  2. The jobs for the pages that appear to not have page_props just have not 
executed yet?
  3. something else?
  
  Looking at 
https://grafana.wikimedia.org/d/CbmStnlGk/jobqueue-job?orgId=1&var-dc=eqiad%20prometheus%2Fk8s&var-job=refreshLinks
 though these jobs shoul only take a few hours at most?
  But really this is ~15 mins currently.
  This lines up with what @Michael @Jakob_WMDE and I were seeing between 
testwiki and testwikidata, but not with what is seen in T233520 
<https://phabricator.wikimedia.org/T233520> on commonswiki?

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

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

To: Michael, Addshore
Cc: Krinkle, daniel, Jakob_WMDE, Mike_Peel, Aklapper, Jheald, 
Lucas_Werkmeister_WMDE, Addshore, WMDE-leszek, aaron, tstarling, LibrErli, 
Lea_Lacroix_WMDE, Ladsgroup, RolandUnger, Urbanecm, Bencemac, Tacsipacsi, 
Kizule, CCicalese_WMF, Lydia_Pintscher, Invadibot, maantietaja, Muchiri124, 
Hazizibinmahdi, CBogen, Akuckartz, Iflorez, WDoranWMF, alaa_wmde, holger.knust, 
EvanProdromou, Nandana, Lahi, Gq86, Ramsey-WMF, GoranSMilovanovic, QZanden, 
LawExplorer, Poyekhali, _jensen, rosalieper, Agabi10, Taiwania_Justo, 
Scott_WUaS, Pchelolo, Jonas, Ixocactus, Wong128hk, Wikidata-bugs, aude, 
El_Grafo, Dinoguy1000, Steinsplitter, Mbch331, Keegan
_______________________________________________
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