Change #1228627 had a related patch set uploaded (by TrainBranchBot; author: trainbranchbot):

[mediawiki/core@wmf/1.46.0-wmf.12] Branch commit for wmf/1.46.0-wmf.12

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

Change #1228627 merged by jenkins-bot:

[mediawiki/core@wmf/1.46.0-wmf.12] Branch commit for wmf/1.46.0-wmf.12

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

Change #1228694 had a related patch set uploaded (by TrainBranchBot; author: MediaWiki PreSync):

[operations/mediawiki-config@master] testwikis to 1.46.0-wmf.12

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

Change #1228694 merged by jenkins-bot:

[operations/mediawiki-config@master] testwikis to 1.46.0-wmf.12

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

Mentioned in SAL (#wikimedia-operations) [2026-01-20T04:03:27Z] <mwpresync@deploy2002> Started scap sync-world: testwikis to 1.46.0-wmf.12 refs T413803

Mentioned in SAL (#wikimedia-operations) [2026-01-20T04:47:42Z] <mwpresync@deploy2002> Finished scap sync-world: testwikis to 1.46.0-wmf.12 refs T413803 (duration: 44m 14s)

Could you please merge the https://gerrit.wikimedia.org/r/c/mediawiki/extensions/GlobalWatchlist/+/1229000? I checked my own change that was merged to this version on testwiki this morning, and found a bug for more complex cases, which I did test, but looks like not good enough in this partcular point. Fortunately, testwiki does not use its own data, but fetches it all from across the Wikimedia wikis instead, it makes much easier to check on actual data, a lot of it, and I do it every Tuesday morning, and it actually helped this time. The extension is on Meta only from all the Wikimedia wikis, in group1, so it's about 31 hours left to fix it. My explanation for the bug: I was an idiot. I hope I'll be forgiven, I'm writing patches just for a month. Thank you in advance.

Change #1229069 had a related patch set uploaded (by TrainBranchBot; author: Andre Klapper):

[operations/mediawiki-config@master] group0 to 1.46.0-wmf.12

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

@IKhitron: Hi, that patch first needs a review by someone who knows that code area, to get it merged into the git master branch. Afterwards, it needs to get backported to the 1.46.0-wmf.12 branch that we deploy this week to the wikis. You may want to reopen the corresponding task for that patch, and mark it as a train blocker if you think that merging it should block the group1 deployment. Thanks!

Change #1229069 merged by jenkins-bot:

[operations/mediawiki-config@master] group0 to 1.46.0-wmf.12

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

In T413803#11535882, @Aklapper wrote:

@IKhitron: Hi, that patch first needs a review by someone who knows that code area, to get it merged into the git master branch. Afterwards, it needs to get backported to the 1.46.0-wmf.12 branch that we deploy this week to the wikis. You may want to reopen the corresponding task for that patch, and mark it as a train blocker if you think that merging it should block the group1 deployment. Thanks!

Thank you for the explanation. I do not think it's a blocker, IMHO, because it changes only one of the parts that was added in original change. So, the original change does not break anything, it just add sometimes incorrect information. But I do not know how it's supposed to be decided, so maybe it is a blocker. I'll do this.

Mentioned in SAL (#wikimedia-operations) [2026-01-20T09:21:07Z] <aklapper@deploy2002> rebuilt and synchronized wikiversions files: group0 to 1.46.0-wmf.12 refs T413803

Thanks for catching that GlobalWatchlist bug @IKhitron. As far as I can see, the bug is that, when using the "Group results by page" option, and a page has been created, the "permanent link" item (newly added last week) links to the latest revision of the page, instead of the first revision.

This is a very subtle issue and definitely not a train blocker (which means no other changes could be deployed until it is fixed; only serious problems like the whole page not loading would qualify).

If the bug is problematic for you, then you could schedule a backport of the patch to get it deployed sooner (see https://wikitech.wikimedia.org/wiki/Backport_windows#How_to_submit_a_patch_for_backport). Personally, I would just wait until next week's scheduled deployment takes care of it, it seems like a small problem and backport deployments are a bit tedious.

In T413803#11539595, @matmarex wrote:

Thanks for catching that GlobalWatchlist bug @IKhitron. As far as I can see, the bug is that, when using the "Group results by page" option, and a page has been created, the "permanent link" item (newly added last week) links to the latest revision of the page, instead of the first revision.

This is a very subtle issue and definitely not a train blocker (which means no other changes could be deployed until it is fixed; only serious problems like the whole page not loading would qualify).

If the bug is problematic for you, then you could schedule a backport of the patch to get it deployed sooner (see https://wikitech.wikimedia.org/wiki/Backport_windows#How_to_submit_a_patch_for_backport). Personally, I would just wait until next week's scheduled deployment takes care of it, it seems like a small problem and backport deployments are a bit tedious.

Thanks a lot, @matmarex. I trust you. And also, I don't like the patch waiting a full week, but, looking on the rules of backporting, I can see there is no choice, it does not fit the criterias. And the Beta wikis are down now, there is just not enough time. The second best is to mention this bug fix next time there will be an entry for the extension in the Tech News, whenever that will be. It will tell the world I made a mistake, but it's better than people will try, see it's wrong, and do not use it, because they don't know it was fixed. But I'm curious if there is a chance to add to Meta common.js a line $('.ext-globalwatchlist-permalink').remove();, just for this week. What do you think?
And about the bug, it happens indeed in some of the cases you described.

In T413803#11539622, @IKhitron wrote:

And the Beta wikis are down now, there is just not enough time.

The outage from T415113: HAProxy failing to start on deployment-cache-text08 and deployment-cache-upload08 because of missing `traffic_class.lua` library has been resolved.

In T413803#11539595, @matmarex wrote:

Thanks for catching that GlobalWatchlist bug @IKhitron.

Summary for all this topic: I will not ask backporting, just wait for next week. I asked on m:MediaWiki talk:Common.css to show a little message for the users, don't know if they will agree. That's all with it, thank you all for your help.

Change #1229522 had a related patch set uploaded (by TrainBranchBot; author: Andre Klapper):

[operations/mediawiki-config@master] group1 to 1.46.0-wmf.12

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

Change #1229522 merged by jenkins-bot:

[operations/mediawiki-config@master] group1 to 1.46.0-wmf.12

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

Mentioned in SAL (#wikimedia-operations) [2026-01-21T09:09:46Z] <aklapper@deploy2002> rebuilt and synchronized wikiversions files: group1 to 1.46.0-wmf.12 refs T413803

Since deployment of 1.46.0-wmf.12 to group1, Commons experiences DBTransactionErrors on webvideotranscode hosts: T415169: Transcode jobs failing with Wikimedia\Rdbms\DBTransactionError: Transaction round stage must be 'cursory' (not 'within-commit')
I also brought this up in WMF's internal #talk-to-data-engineering channel.
Given similar existing Phab tickets I do not think that this justifies a rollback until someone tells me to do so.

Following up from T415169, I suspect video transcodes are no longer completing due to this error. Can we roll the wmf.12 back to group 0? (i.e., get commons back to wmf.11)

Change #1229622 had a related patch set uploaded (by TrainBranchBot; author: Andre Klapper):

[operations/mediawiki-config@master] group0 to 1.46.0-wmf.12

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

Change #1229622 merged by jenkins-bot:

[operations/mediawiki-config@master] group0 to 1.46.0-wmf.12

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

Due to T415169 I am rolling back wmf.12 to group0 right now, so group1 will be back on wmf.11

Mentioned in SAL (#wikimedia-operations) [2026-01-21T18:11:02Z] <aklapper@deploy2002> rebuilt and synchronized wikiversions files: group0 to 1.46.0-wmf.12 refs T413803

Change #1230250 had a related patch set uploaded (by TrainBranchBot; author: Andre Klapper):

[operations/mediawiki-config@master] group1 to 1.46.0-wmf.12

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

Change #1230250 merged by jenkins-bot:

[operations/mediawiki-config@master] group1 to 1.46.0-wmf.12

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

Backported/deployed https://gerrit.wikimedia.org/r/c/mediawiki/extensions/TimedMediaHandler/+/1229724 to revert the offending change on the 1.46.0-wmf.12 branch only - T415169

Mentioned in SAL (#wikimedia-operations) [2026-01-22T09:26:44Z] <aklapper@deploy2002> rebuilt and synchronized wikiversions files: group1 to 1.46.0-wmf.12 refs T413803

Change #1230255 had a related patch set uploaded (by TrainBranchBot; author: Andre Klapper):

[operations/mediawiki-config@master] group2 to 1.46.0-wmf.12

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

Change #1230255 merged by jenkins-bot:

[operations/mediawiki-config@master] group2 to 1.46.0-wmf.12

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

Mentioned in SAL (#wikimedia-operations) [2026-01-22T09:44:35Z] <aklapper@deploy2002> rebuilt and synchronized wikiversions files: group2 to 1.46.0-wmf.12 refs T413803