I have downloaded refs/changes/62/808262/29 and it works for me (on mariadb/mysql)

SELECT cuc_namespace,cuc_title,cuc_user,cuc_user_text,cuc_comment,cuc_actiontext,cuc_timestamp,cuc_minor,cuc_page_id,cuc_type,cuc_this_oldid,cuc_last_oldid,cuc_ip,cuc_xff,cuc_agent FROM `cu_changes` FORCE INDEX (cuc_ip_hex_time) JOIN `user` ON ((cuc_user=user_id)) WHERE cuc_ip_hex = 'v6-00000000000000000000000000000001' AND (cuc_user != 0) AND ((user_editcount < 500) OR (user_registration > '20220716210205')) ORDER BY cuc_timestamp DESC LIMIT 5001

In T315195#8155330, @Dreamy_Jazz wrote:

That looks to be the same problem as here. I'll try that out and see if it works.

I'm not sure this addresses this task, unless I'm misunderstanding something, as it's not possible to use a FORCE INDEX on a JOIN condition. I say this because otherwise the SQL query validator would have said it was valid (as it doesn't know what tables a index corresponds to). As such there IMO needs to either be a more descriptive error (something that says you can't have a FORCE INDEX with a JOIN unless the index is attached to a table) or the SQL Builder needs to understand that by default the index goes before any joins.

Have found the corresponding bug for your "feature" request: T274618: Return actual integers when selecting integer fields from the DB

In T315224#8155280, @Dreamy_Jazz wrote:

Ah. Okay. Thanks for that information.

All returns from the database are strings. If the database does not convert a wrongly given default, that sounds like a bug there. Mysql has accept the default, because it can cast the string 0 to a numeric 0.

The mediawiki database layer returns everything as string, even it is integer in the database.

Sounds similiar to T253489#6163546, just say for which table the index is

It now passed on the the patch https://gerrit.wikimedia.org/r/c/mediawiki/core/+/822708 from today
FAILURE: https://integration.wikimedia.org/ci/job/mediawiki-quibble-composer-mysql-php80-docker/407/consoleFull
PASS: https://integration.wikimedia.org/ci/job/mediawiki-quibble-composer-mysql-php80-docker/408/consoleFull

I have also seen the segfault on https://gerrit.wikimedia.org/r/c/mediawiki/core/+/816261, but assumed it was for the changed tests, not flaky.

In T300463#8108195, @Stashbot wrote:

Mentioned in SAL (#wikimedia-releng) [2022-07-27T13:55:56Z] <James_F> Zuul: [mediawiki/core] Add a non-vendor php80 job for main branch T300463

The inserted options rcenhancedfilters-seen-tour and wlenhancedfilters-seen-tour are set in LocalUserCreated hook (from the WikimediaMessages extensions, but there are more extensions as well).

The best support for mysql is to remove the EXISTS check. It seems only exists on DROP TABLE, but not on other DDL statements

UNIQUE INDEX cx_translation_ref (
  translation_source_title, translation_source_language,
  translation_target_language, translation_started_by
),

The refered unique index contains a user id, so this could be a double-click or something which is trying to store the same thing twice over the api (ApiContentTranslationSave)

The log message cannot longer happen since https://gerrit.wikimedia.org/r/c/mediawiki/core/+/758592, because Timeouts are rethrown and not logged anymore

The backlog for that template is now processed after a fresh recursive link update has been started via api's action=purge

The job queue is designed to do the reparses, because that does not fit into one only transaction, wikitext processing is expensive.

Sounds like a sub task of T304979 or at least related

The index get dropped with T314041

The deletion of templatelinks is done via the job queue, because reparsing many pages takes some time. The counts are at 0 now.

Flow produce its own recent changes line and set the type RC_FLOW to 142, that is what you are seeing. As the core types are known there are mapped to the string values (via RecentChange::parseFromRCType), but flow is not known there.

In T279585#6982103, @LucasWerkmeister wrote:

Hm, thanks. If I add contentmodel text/x-wiki, I get an internal error instead: https://www.wikidata.org/w/api.php?action=parse&format=json&summary=summary&prop=&contentformat=text%2Fx-wiki

{
    "error": {
        "code": "internal_api_error_InvalidArgumentException",
        "info": "[0009a4bd-06fa-48c2-a925-b7875275e3d3] Caught exception of type InvalidArgumentException",
        "errorclass": "InvalidArgumentException"
    },
    "servedby": "mw1346"
}

I guess that must be because of the missing text. If I add text as empty, then it works. (But there are also more warnings, because it’s still not a proper content parse request – except I’m not interested in parsing content in the first place, only the edit summary. But apparently something changed that makes parsing the summary alone more difficult?)

Anyways – if this is indeed exclusive to Wikidata (and Test Wikidata, I guess – do we have other wikis where the main namespace is not wikitext?), then this probably doesn’t need to block the train.

Without further parameter on the request url it is hard to tell which api module is affected, but this is commons and long transactions on upload was improved with https://gerrit.wikimedia.org/r/c/mediawiki/core/+/735762 (part of T283045)

addWiki.php is documented to get run on another wiki, while creating a new wiki and this is the addition of the main page to the new wiki (https://guw.wikipedia.org/w/index.php?oldid=1&uselang=en matched also this bug creation timestamp)

Fixed by https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Lingo/+/700839

$wgUser was already removed with T242679, $wgTitle and $wgOut still there

There are also some unneeded deletion on the preferences, which could hold locks as well, see T301506

@DBA, @Performance Team:

I fixed that indirectly with a replacement in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/UserMerge/+/759828 which is in 1.38

$wgAbuseFilterNotifications = 'rc' or 'rcandudp' is broken as well and throws CannotCreateActorException (it's post send, not visible to the wiki), the proposal does not fix that part (because CheckUser would be called from RecentChanges for that configs)

First collection with the abstract schema file names (as of now) and some dblist entries

In T314087#8114248, @Marostegui wrote:

We can just do it in the same transaction: alter table cx_translators drop key cx_translation_translators, add PRIMARY KEY ( translator_user_id, translator_translation_id );

The equivset is to handle "Visually similar characters". The persian digits are semantical identical and mediawiki already supports that with $digitTransformTable in the language file.

There is already another mapping for that character

In T65217#3678572, @Huji wrote:

I think mass importing Unicode's confusables is the best option @kaldari

The database field spoofuser.su_name should be made binary to be equal to the field user.user_name and behaviour correctly when the database collation not defaults to binary

Handled by https://gerrit.wikimedia.org/r/c/mediawiki/extensions/AbuseFilter/+/634652

Just as note to avoid confusing: The fix only applied to new log entries after the deployment, because the changed code is used on store into check user, not on read of the stored data

A deprecation notice should not break your wiki, the message may be shown and it looks broken.

In T311308#8026100, @AlexisJazz wrote:

I'm thinking maybe this is a kind of edit conflict, my script changes two different preferences at practically the same time. I wouldn't expect an issue since it's not the same preference, but maybe it's an issue anyway.

There is a setting named for that: https://www.mediawiki.org/wiki/Manual:$wgExtraGenderNamespaces