Page MenuHomePhabricator

Unhandled internal error from page deletion during Special:MovePage (Fatal MWException)
Open, Needs TriagePublic




[XHVEJwpAMFsAAGPp5WoAAABJ] 2019-02-26 13:50:31: Fatal exception of type "MWException"
unavailable to @revi.


Cannot move a page, also documented at SRM.


Event Timeline

revi created this task.Feb 26 2019, 1:53 PM
Restricted Application added a project: User-revi. · View Herald TranscriptFeb 26 2019, 1:53 PM
revi moved this task from Incoming to Radar on the User-revi board.Feb 26 2019, 1:54 PM
Daimona added a subscriber: Daimona.EditedFeb 26 2019, 1:56 PM

This doesn't really need a trace, as it's AbuseFilter-related. More specifically, a local AbuseFilter is preventing the deletion phase of the move. I'll go ahead and search the offending filters, which as a good principle should have user groups checks in place...

EDIT: AbuseFilter 25.

exception.file	       	/srv/mediawiki/php-1.33.0-wmf.18/includes/MovePage.php:497
exception.message	       	Failed to delete page-move revision:
#0 /srv/mediawiki/php-1.33.0-wmf.18/includes/MovePage.php(263): MovePage->moveToInternal(User, Title, string, boolean, array)
#1 /srv/mediawiki/php-1.33.0-wmf.18/includes/specials/SpecialMovepage.php(606): MovePage->move(User, string, boolean)
#2 /srv/mediawiki/php-1.33.0-wmf.18/includes/specials/SpecialMovepage.php(128): MovePageForm->doSubmit()
#3 /srv/mediawiki/php-1.33.0-wmf.18/includes/specialpage/SpecialPage.php(569): MovePageForm->execute(NULL)
#4 /srv/mediawiki/php-1.33.0-wmf.18/includes/specialpage/SpecialPageFactory.php(558): SpecialPage->run(NULL)
#5 /srv/mediawiki/php-1.33.0-wmf.18/includes/MediaWiki.php(288): MediaWiki\Special\SpecialPageFactory->executePath(Title, RequestContext)
#6 /srv/mediawiki/php-1.33.0-wmf.18/includes/MediaWiki.php(867): MediaWiki->performRequest()
#7 /srv/mediawiki/php-1.33.0-wmf.18/includes/MediaWiki.php(517): MediaWiki->main()
#8 /srv/mediawiki/php-1.33.0-wmf.18/index.php(42): MediaWiki->run()
#9 /srv/mediawiki/w/index.php(3): require(string)
#10 {main}

Thanks @Aklapper. BTW, @revi, the quick obvious solution is to add a user groups check to the offending filter. If, however (as GTranslate hints) the filter is meant to target sysops as well, then they should follow the instructions given in the warning message for filter 25, or tune the filter itself.
On our end, this failure should be handled much more gracefully and possibly reported to the user somehow instead of a plain $status->isGood check. Filtering deletion on page move makes sense too, IMHO (if the move involves a deletion).

Daimona moved this task from Backlog to Future on the User-Daimona board.Feb 27 2019, 4:17 PM
revi added a comment.Feb 28 2019, 9:39 AM

@Daimona: I'm a steward and does not have thwiki community approval to make such change. I'll make sure community sysop see this.

@revi Yes sure, that's what I meant, although probably I should have stated it on meta too :-) Thanks!

Horus added a subscriber: Horus.Feb 28 2019, 3:24 PM

I've disable the abuse filter in question and made it public for further review. Please feel free to make any changes.

Horus added a comment.Feb 28 2019, 3:28 PM

The filter is intended to detect malicious word in edit summary, so I'm not sure why it block page move. (Auto-generated page move edit summary isn't in the filter.)

@Horus thanks! Actually, while filtering page deletion upon moving, the auto-generated summary is included. This is the message, where $1 is the old title ("เจ้ากรรมนายเวร (ละครโทรทัศน์)" in this case), and the whole message is matched by the filter regex.

Horus added a comment.Feb 28 2019, 3:42 PM

Thanks for pointing it out. Removed the problematic word. Seems unreasonable to detect a short word which can easily go wrong.

@Daimona The technical problem is that an AbuseFilter match on page deletion (during move) causes a fatal error.

Do you know if the cause for that is in AbuseFilter, or in MovePage code? What it should do is report a normal message to the user.

@Krinkle IMHO this should be handled in core. Failures of deletion during page move should show up to the user like the ones for normal deletions do, instead of throwing.

Krinkle renamed this task from Fatal exception of type "MWException" when trying to move a page on thwiki to Unhandled internal error from page deletion during Special:MovePage (Fatal MWException).Apr 19 2019, 8:13 PM
Krinkle moved this task from To triage to Move/Merge on the MediaWiki-Special-pages board.
Krinkle added a subscriber: BPirkle.

@Daimona Thanks, I didn't realise that regular Page deletion already does this. That makes a good case for handling this here as well, and also means we may have an existing pattern that we can apply with relative easy (being optimistic).

I recall this code being changed as part of the commit last quarter that refactored page deletion to use the JobQueue. It involved a few changes to implicit deletes as well. It's possible this may've caused the internal error to no longer be handled. (T198176)

CC-ing @BPirkle and tagging CPT who worked on that and might know more about this.

I was indeed involved with the changes to delete via the job queue for pages with "many" revisions. However, I don't think that change is related to this issue. I was able to reproduce (on a local test wiki) the Internal Error behavior with AbuseFilter (plus an appropriate filter) on a version of Mediawiki from before T198176.

With that said, I'm not trying to avoid making changes. The current behavior is indeed undesirable.

EvanProdromou added a subscriber: EvanProdromou.

Looks like the CPT effort on this is minimal so I'm untagging us. Feel free to loop us back in if that's incorrect.

Krinkle added a comment.EditedMay 6 2019, 5:59 PM

@EvanProdromou Do you mean CPT will fix this soon without tracking on a workboard, or do we need to tag a different team instead? It is currently without a team tag, which seems odd. It is an application crash found in currently deployed code that causes user actions to fail.