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.

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: 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!

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

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.

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.

@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.

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.

@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.