Unexpected permanently locked pages (bug occuring randomly, caused by SemanticMediawiki for its "change propagation")

Note: this text was initially in Translating:Localisation for developers, but it was deleted by some admin not understanding this issue which is still there since years.

Restored here, because this bug still needs tracking on this Wiki which is affected since very long (without any change by translatewiki admin to try solving it, even if it is demonstrated here, even if it affects also many other wikis using the same SemanticWiki extension, where their admins still don't have any hint about what to do for at least paliating this problem).

Due to a bug in the "SemanticMediawiki" extension of Mediawiki, an addition/change/removal of categorisation for any created or modified page, may unexpectedly and unpredictibly lock this page permanently after the edit is saved. Anyone is seeing the message at top of the page, when trying to edit such page, and the page would then be uneditable by anyone, even by a site administrator (unless a specific admin-only but dangerous tool is used that will bypass many checks for replacing any content in "raw mode", or they use admin-only tools to directly update the SQL database, which can further break normal caching behavior of MediaWiki, or could seriously damage the data integrity of SemanticMediaWiki):

You do not have permission to edit this page, for the following reason:
⧼Smw-change-propagation-protection⧽

This is apparently caused by a race condition where a background job can be set to run later in one thread, when it has in fact already run in another thread and terminated trying to remove this temporary status, before the pending "Change propagation::+" status has been actually stored in the database. (See initial bug 2494 in GitHub, opend on 3 Jun 2017 then closed without being fixed, then bug 4344 still unsolved since 27 Oct 2019). However some other investigations found that it may be related to lack of synchronization between different caches, with a normal database cache used by the front webserver for navigation and page editing, and another optimistic fast cache used temporarily in memory only by the background CLI jobs, whose state is cleared but never reflected into the normal database cache used by the front webserver to check the editable status of these pages (these CLI jobs do not lock any normal database records, and also do not monitor concurrent changes on the datase possibly made interactively on the front server, they assume database caches are coherent, but unfortunately they are not).

Currently, these affected pages are the following (new pages may appear at any time, refresh this list by clicking the UTC clock gadget displayed at top of this page; you can activate this gadget in your preferences) to run again the SemanticMediawiki query and regenerate this report):

{{#ask:Change propagation::+

|?Modification date#-F[Y-m-d H:i:s]@en
|sort=Modification date |order=asc
|offset=0 |limit=500
|link=all
|format=table |class=wikitable sortable smwtable
|headers=show
|searchlabel=more... 
}}

Also, there are some additional categories showing this related message in a red banner when just visiting them:

⧼Smw-category-change-propagation-locked-error⧽

They seem to use another SemanticMediaWiki property (still not identified). May be this is not a property but a bug that occured while the background job was running then failed, causing the job to remain in unterminated state, even if the change propagation property was removed, but this has the same effect and the affected page are also locked and permanently left not editable (no pending job will remove this broken status).

This last bug seems to affect double redirected categories (with a false unchecked assumption made by the SemanticMediaWiki background job, causing it to crash prematurely): they are listed on Special:DoubleRedirects but it's not possible to fix these broken redirects to the correct target category: when editing them, the first message shown above appears. This is not caused by the same SemanticMediaWiki property, but by another internal state (still not determined); this state is possibly not stored in the database by a documented property but could be caused internally by the hook code of SemanticMediawiki extension itself.

Note that SemanticMediaWiki is not supposed to manage any semantic properties for redirected categories that it officially "does not support". However SemanticMediaWiki should not break Mediawiki itself (even if these redirects are valid but the target is also redirected, or because there's a typo made by the contributor in the edited redirect). Hard redirects on categories are possible, useful when they are related to exact synonyms, and valid when they are empty (no members). There are also simple ways to check that they effectively remain empty and maintain this (by using a category tracking template, just below the redirect itself in the category page).

Verdy p (talk)‎