Michael added a comment.
incremental progress update: I managed to connect the tentative starting point ChangeHandler <https://github.com/wikimedia/Wikibase/blob/b4cb0620fd5b6b96e11d43ea67af840f78f355f6/client/includes/Changes/ChangeHandler.php#L122> (you can see ChangeHandlers bigger context in the new arch docs <https://wmde.github.io/wikidata-wikibase-architecture/systems/WikibaseClient/06-Runtime_View.html#entity-change-notifications>) with the likely endpoint ClientParserOutputDataUpdater <https://github.com/wikimedia/Wikibase/blob/b4cb0620fd5b6b96e11d43ea67af840f78f355f6/client/includes/ParserOutput/ClientParserOutputDataUpdater.php#L98>. The assumption is that the problem is somewhere between those two places in the code. - `\Wikibase\Client\Changes\ChangeHandler::handleChange` is where we start - One of that methods main actions is to call `\Wikibase\Client\Changes\WikiPageUpdater::scheduleRefreshLinks` - which creates a new `\RefreshLinksJob` and adds it to the job queue via `\JobQueueGroup::lazyPush` - In that constructor a field `removeDuplicates` is probably set to true in our case - maybe our job gets deduplicated with one that doesn't do the trick? - at some point that job is `\RefreshLinksJob::run` and executes the private method `\RefreshLinksJob::runForTitle` - that `runForTitle` method then requests `\RefreshLinksJob::getParserOutput` - This method eventually gets fresh parser output, but checks a couple of conditions first, one looks particularly suspect: $cachedOutput = $this->getParserOutputFromCache( $parserCache, $page, $revision, $stats ); if ( $cachedOutput ) { return $cachedOutput; } - however, 1. we should have dealt with that by unsetting rootJobTimestamp <https://gerrit.wikimedia.org/r/c/574868> 2. This should not have been an issue in the first place, because if the timestamp that this job was generated is older than the time when the ParserOutput was last cached, then that means that the the ParserOutput has been generated in the meantime and the changes should have been picked at that moment anyway - That being said, if there is seemingly no cached output, then it should be generated by `\MediaWiki\Revision\RenderedRevision::getRevisionParserOutput` which is too complex for me to dive into, until I have a good reason to suspect that the issue lies somewhere inside - but I assume at some point `\AbstractContent::getParserOutput` gets called - which runs the hook `onContentAlterParserOutput` (c.f. official docs for the hook ContentAlterParserOutput <https://www.mediawiki.org/wiki/Manual:Hooks/ContentAlterParserOutput>) - And we have a handler registered for that hook: `\Wikibase\Client\Hooks\ParserOutputUpdateHookHandler::onContentAlterParserOutput` - That handler ultimately calls the last step `\Wikibase\Client\ParserOutput\ClientParserOutputDataUpdater::updateItemIdProperty` which is supposed to modify the page props Something in that chain above is probably broken under some conditions. Preliminary learning/confusion: We don't actually care about the main functionality of `RefreshLinksJob`, we care about the ParserOutput being recreated. TASK DETAIL https://phabricator.wikimedia.org/T280627 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Michael Cc: 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 https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
