Seems like an AbuseFilter problem:

8eacd097-c049-480a-a068-9bc12fef99e4] /w/index.php?title=Speci%C3%A1lis:Lap_%C3%A1tnevez%C3%A9se&action=submit   MWException from line 832 of /srv/mediawiki/php-1.36.0-wmf.11/includes/MovePage.php: Failed to delete page-move revision: This action has been automatically identified as harmful, and therefore disallowed.
If you believe your action was constructive, please inform an administrator of what you were trying to do.
A brief description of the abuse rule which your action matched is: Szócikk teljes tartalmának eltávolítása
#0 /srv/mediawiki/php-1.36.0-wmf.11/includes/MovePage.php(575): MovePage->moveToInternal(User, Title, string, boolean, array)
#1 /srv/mediawiki/php-1.36.0-wmf.11/includes/MovePage.php(421): MovePage->moveUnsafe(User, string, boolean, array)
#2 /srv/mediawiki/php-1.36.0-wmf.11/includes/specials/SpecialMovepage.php(658): MovePage->moveIfAllowed(User, string, boolean)
#3 /srv/mediawiki/php-1.36.0-wmf.11/includes/specials/SpecialMovepage.php(137): MovePageForm->doSubmit()
#4 /srv/mediawiki/php-1.36.0-wmf.11/includes/specialpage/SpecialPage.php(600): MovePageForm->execute(NULL)
#5 /srv/mediawiki/php-1.36.0-wmf.11/includes/specialpage/SpecialPageFactory.php(709): SpecialPage->run(NULL)
#6 /srv/mediawiki/php-1.36.0-wmf.11/includes/MediaWiki.php(307): MediaWiki\SpecialPage\SpecialPageFactory->executePath(Title, RequestContext)
#7 /srv/mediawiki/php-1.36.0-wmf.11/includes/MediaWiki.php(940): MediaWiki->performRequest()
#8 /srv/mediawiki/php-1.36.0-wmf.11/includes/MediaWiki.php(543): MediaWiki->main()
#9 /srv/mediawiki/php-1.36.0-wmf.11/index.php(53): MediaWiki->run()
#10 /srv/mediawiki/php-1.36.0-wmf.11/index.php(46): wfIndexMain()
#11 /srv/mediawiki/w/index.php(3): require(string)
#12 {main}

Of course, it should be shown as a normal error, not as an exception.

And it should not match the filter in the first place—in the 10–11th lines, the filter tries to exclude redirections/renames, which is the attempted action here. (I’m not sure if it’s a bug in the filter or in the extension, but the filter looks good for me at first sight.)

In T265779#6557103, @Tgr wrote:

Seems like an AbuseFilter problem:
Of course, it should be shown as a normal error, not as an exception.

It does not seem to be AbuseFilter fault. AbuseFilter uses ArticleDeleteHook to filter deletion action (in this case). It founds the deletion should be disallowed (as configured) and the hook requires boolean return value to decide on whether to proceed with the deletion or not. So it's obvious, the only option for AbuseFilter is to return false to abort the deletion. It also sets the correct error message by modifying the supplied error variable in the hook. That's all it could do.

So the problem lies in MovePage, with its logic that if target page deletion fails, then exception will follow

$status = $newpage->doDeleteArticleReal(...)
if ( !$status->isGood() ) {
     throw new MWException( 
     'Failed to delete page-move revision: ' . $status->getWikiText( false, false, 'en' )  );
}

In T265779#6557190, @Ammarpad wrote:

In T265779#6557103, @Tgr wrote:

Seems like an AbuseFilter problem:
Of course, it should be shown as a normal error, not as an exception.

It does not seem to be AbuseFilter fault. AbuseFilter uses ArticleDeleteHook to filter deletion action (in this case). It founds the deletion should be disallowed (as configured) and the hook requires boolean return value to decide on whether to proceed with the deletion or not. So it's obvious, the only option for AbuseFilter is to return false to abort the deletion. It also sets the correct error message by modifying the supplied error variable in the hook. That's all it could do.

So the problem lies in MovePage, with its logic that if target page deletion fails, then exception will follow

MovePage.php

$status = $newpage->doDeleteArticleReal(...)
if ( !$status->isGood() ) {
     throw new MWException( 
     'Failed to delete page-move revision: ' . $status->getWikiText( false, false, 'en' )  );
}

I agree with every single word here. MW core is throwing an unhandled exception if the deletion fails, which is certainly not an impossible scenario (and can have lots of different causes, not only AbuseFilter).

Of note, this is not the first time I see a bug report about this issue, but no matter how hard I tried, I cannot find a duplicate.

SpecialMovePage is also calling doDeleteArticleReal and shows the error message (thats happen when the sysop is using the move-and-delete option and that fails)
In this case it is a move-over-redirect which is aborted by AbuseFilter and not reported nicly.

Maybe using a ErrorPageError instead of MWException? It is not possible to return the Status to the caller

throw new ErrorPageError( 'internalerror', $status->getMessage() );

I think these are related: T217136, T210845

In T265779#6557325, @Umherirrender wrote:

It is not possible to return the Status to the caller

I think it shouldn't be terribly hard. MovePage::moveToInternal is private and it has a single caller, so any change would be self-contained. We might change the method to return a Status object (wrapping the revision in case of success), and check/merge the Status inside moveUnsafe.

@Ammarpad Let us know if you need support or code review on this. Untagging Platform Engineering for now

Change 635407 had a related patch set uploaded (by Ammarpad; owner: Ammarpad):
[mediawiki/core@master] MovePage: Handle target page deletion failure gracefully.

https://gerrit.wikimedia.org/r/635407

@Clarakosi For code review

Change 635407 merged by jenkins-bot:
[mediawiki/core@master] MovePage: Handle target page deletion failure gracefully.

https://gerrit.wikimedia.org/r/635407