In T232081#5719505, @Umherirrender wrote:

Deletion on change_tag is not done by the primary key in ChangeTags::updateTags, maybe some gap looks make problems here.
Changing to select + delete primary key could help

If needed that should be another bug, maybe stalled for the begin as dead code detection takes more memory and more cpu.
It can bring in more suppressions as we have at the moment with the redundant detection plugin.

The information if a block was partial or sidewide is only stored in the param blob of the log.

Deletion on change_tag is not done by the primary key in ChangeTags::updateTags, maybe some gap looks make problems here.

I cannot read that language and working with right-to-left words is hard for me, but it looks like the extra namespace in pswiki.

Maybe when using strict sql mode this results in an error and not in a number conversion of all rows of that column

When using the "undo" function in the history the notification is send to the revision id provided with that request.
But than the history should also show "Tag: Undo", that is not visible here.

The error message is

Return type hints are used more and more. I would also support more spaces here ") : "

HHVM was using an older version of phpunit, so it may be fixed in the newer one (phpunit 6 or later).

It seems that due to the actor migration the api now says it is anon

You could validate the input field on the server side and than add a error message when used with the wrong values.

The code was worked on in https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/Wikibase/+/543868/

May fixed by T236320, because it has the same error message and stack trace

In T237591#5649701, @Luke081515 wrote:

I have this also on https://de.wikipedia.org/wiki/Liste_der_Landkreise_in_Deutschland:

There is T239062 for the "Revision doesn't belong to page" error

There is a commit message validator tool, it maybe set up with an option that a bug required and than run by jenkins

The query works with a smaller limit on result and days
https://www.wikidata.org/wiki/Special:RecentChanges?hidebots=1&reviewStatus=unpatrolled&hidepreviousrevisions=1&hidecategorization=1&namespace=12%3B120%3B146%3B640%3B828&limit=1&days=1&enhanced=1&urlversion=2

After resolving the redirect in ApiEditPage there is no check for Title::isExternal or Title::canExist (to check for Special or Media namespace redirect targets)

DatabaseBlock can use both connections

		$db = wfGetDB( $fromMaster ? DB_MASTER : DB_REPLICA );

The last question is, if this should be done also for unset()

The last stack trace shows a image - https://he.wikiquote.org/wiki/קובץ:Pluvianus_aegyptius_3_Luc_Viatour.jpg

With T165817 a \b was added which should avoid your issues, it is part of REL1_30

I would say that is https://en.wikipedia.org/w/api.php?action=help&modules=setnotificationtimestamp with entriewatchlist

There was a rename of the user

Maybe the query is to complex. The query must look similar to this one (depending on the actor and comment migration stage)

wfEscapeWikiText is called for each parameter of the given parameter list for a message, but it is possible to do more complex parameter params as only strings. Using Message::listParam for example produce an array which cannot be work on with` wfEscapeWikiText`

There are two ways for an empty list. No protection types in $wgRestrictionTypes, but I cannot find that this differ from the default one.
Or the hook TitleGetRestrictionTypes which is used from Wikibase to disable protection for entity namespace. But the gallery is no entity namespace, so that seems not the problem.

Fix in master is https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/485133/

It is also possible to make Exif::exifGPStoNumber better to work with that number