| Addshore added a comment. |
So debugging has lead me to SubmitEntityAction::undo in wikibase, and the following code snippet.
if ( $patchedContent->equals( $latestContent ) ) {
$status = Status::newGood();
$status->warning( 'wikibase-empty-undo' );
} else {
/// ...
}$patchedContent->equals( $latestContent ) returns true, so it appears that the undo action will do nothing hence nothing is done.
The 2 content objects here do indeed have the same content inside (both with the OLD data)$latestRevision correctly has the latest revision ID and text.
$latestRevision->mSlots->slots->main->content{LexemeContent} has the correct blob of JSON, but the Lexeme entity within the content is incorrect showing the previous revision (not the latest)I suspected this was due to LexemeHandler and the special handling for Forms in LexemeHandler::newEntityContent, as an EntityHolder can contain a specific revision of an Entity, and the special case for Forms will load an entity from an EntityLookup which will not have a specified version / revision. But it doesn't look like this special case code for forms it actually called during the undo submit.
It seems that the DeferredDecodingEntityHolder has one blob, the entity object it has does not match.
The trace of the first moment this occurs when DeferredDecodingEntityHolder::getEntity is called can be seen below... (something to do with redirects, doesn't seem relevant, but still probably an issue because of whatever underlying issue is causing all of this)DeferredDecodingEntityHolder.php:98, Wikibase\Content\DeferredDecodingEntityHolder->getEntity() DeferredDecodingEntityHolder.php:132, Wikibase\Content\DeferredDecodingEntityHolder->getEntityId() DeferredCopyEntityHolder.php:60, Wikibase\Content\DeferredCopyEntityHolder->getEntityId() EntityContent.php:129, Wikibase\Lexeme\Content\LexemeContent->getEntityId() EntityContent.php:433, Wikibase\Lexeme\Content\LexemeContent->getRedirectData() EntityContent.php:612, Wikibase\Lexeme\Content\LexemeContent->getPatchedRedirect() EntityContent.php:586, Wikibase\Lexeme\Content\LexemeContent->getPatchedCopy() SubmitEntityAction.php:160, Wikibase\SubmitEntityAction->getPatchContent() SubmitEntityAction.php:113, Wikibase\SubmitEntityAction->undo() SubmitEntityAction.php:66, Wikibase\SubmitEntityAction->show() MediaWiki.php:500, MediaWiki->performAction()The second trace looks a bit more like it might be the cause...
DeferredDecodingEntityHolder.php:98, Wikibase\Content\DeferredDecodingEntityHolder->getEntity() DeferredCopyEntityHolder.php:47, Wikibase\Content\DeferredCopyEntityHolder->getEntity() EntityContent.php:523, Wikibase\Lexeme\Content\LexemeContent->equals() SubmitEntityAction.php:116, Wikibase\SubmitEntityAction->undo() SubmitEntityAction.php:66, Wikibase\SubmitEntityAction->show() MediaWiki.php:500, MediaWiki->performAction()So how does the entity property of $latestRevision get changed to have the content that we want to undo to rather than actually having the latest content?
It looks like there some cloning logic missing from the Lexeme data model, so some mutable objects such as Form don't get cloned, so maintain their references to the originals.
Cc: Lydia_Pintscher, Aklapper, Addshore, WMDE-leszek, Lahi, Gq86, Cinemantique, GoranSMilovanovic, QZanden, LawExplorer, Wikidata-bugs, aude, Darkdadaah, Mbch331
_______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
