T290367 introduced the ChangeHolder which is now used as part of the onRecentChange_save hook to retrieve the Wikibase changes. Unfortunately, as part of change I1d59cbf3faf017a3962fe5c6b54f772e1d4706f2 the behavior for fetching changes was changed from only fetching changes with a matching revision to fetching all changes.
If more than one revision has pending changes, this results in all changes having their metadata (and correspondingly, revisions) overwritten with the metadata from the first change to be processed. This can result in incorrect diffs being generated during change processing and incorrect dispatches to clients.
Description
Description
Details
Details
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| repo: Filter changes by RecentChange revision | mediawiki/extensions/Wikibase | master | +84 -14 |
Related Objects
Related Objects
Event Timeline
Comment Actions
Change 768249 had a related patch set uploaded (by CtrlZvi; author: CtrlZvi):
[mediawiki/extensions/Wikibase@master] Filter changes by RecentChange revision
Comment Actions
I'm trying to understand the underlying context. This issue is what was discussed in the comments on I1d59cbf. It was my understanding back then that only ever the changes related to the given recent changes entry should be in that changeHolder.
Could you elaborate in what situation you noticed the problem? E.g. what wiki and which pages and revisions?
Though @Ladsgroup has probably also a good idea about the potential root cause of this.
Comment Actions
Sure. I have a personal wiki I'm running (currently MW 1.37.1) with some custom extensions. One of these extensions is one I'm developing that will automatically geocode an address (stored in a property on an item) and store the resulting coordinates (into a different property on the same item). This (currently) runs as a deferred update triggered by saving the item with a change to the address property. The process is triggered by the onWikibaseChangeNotification hook which adds the deferred update to do the geocoding then returns.
I haven't traced the precise execution of all deferred jobs to determine the exact order they execute in, but what ends up happening is that before the onRecentChange_save hook is invoked, both property edits have been saved, generating two different revisions, and two different changes (one for each revision) both of which are in the ChangeHolder.
And then, the first recent change is processed, for the first revision, and the change for the second revision has its metadata overwritten to be the first revision. This results in the clients not being notified about the change caused by the second revision (which, in my case, causes the linked page's WikiDataCoord to not get updated).
It's entirely possible that the way in which I'm triggering and saving my automatic geocoding is not the best/right way to go about it (I'm relatively new to MediaWiki development), but it used to work in 1.36, where RecentChanges were only processing the changes associated with their revision.