In T416761#11853274, @matmarex wrote:

ConsumerSubmitControl is somewhat covered now, but the other controls are not covered yet.

@matmarex, yes, I think this one has been significantly covered. Maybe @JTweed-WMF could look at this and conclude, but my opinion would be closing it.

In T418431#11857124, @sbassett wrote:

CR+1, this seems reasonable to me and thanks for the tests. Let's plan to get this deployed during this Monday's (2026-04-27) security deployment window.

Updated the patch to fix PHPUnit tests.

This is now done!

In T414163#11806182, @Ladsgroup wrote:

haha, the repo is archived.

In T422218#11796870, @matmarex wrote:

This is fixed on Wikimedia wikis now.

@daniel, On test wiki + PWB, I got the following response headers with a sessionJwt cookie.

In T417833#11638080, @daniel wrote:

Bumping priority to high, since this blocks the rollout of stage two of the REST API rate limits. It's not sufficient to have this by the rollout date, we need it beforehand so we have visibility of how many clients that use OAuth we would hit with rate limits.

In T420689#11733755, @matmarex wrote:

This reminds me of T409901. It looks like we missed a spot.

Done @sbassett. Thanks for the link @Aklapper!

Attached is a patch for review.

In T418123#11689277, @Tgr wrote:

Do we want to do the same thing for the authentication dashboard?

In T418123#11689277, @Tgr wrote:

Do we want to do the same thing for the authentication dashboard?

In T419226#11690027, @bd808 wrote:

I archived the github repo. I can toggle it back to active for a while if that was done too soon.

In T419226#11682419, @Tgr wrote:

Github, Packagist, not sure if there's anything else.

In T385310#11687492, @Tgr wrote:

Worked:

I believe we can move this to "To be verified in production" for a few weeks and see if situations improve with new data. Also, once the dashboard starts responding faster, we can maybe undo/remove the recording rules and see what happens after that, Cc @Krinkle

Possible related errors are: https://logstash.wikimedia.org/goto/e56bc6a6bdf94ff91056a42f0f0e4c92 and https://logstash.wikimedia.org/goto/408c7433c3a44128f5cbdcf2ecf4c67d.

https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1237951 actually passed and merged on another try. This was probably just a selenium fluke.

Not sure exactly which Wikibase tag to use here or what other tag is related. The issue seems like a DB connection error.

Just checked the https://grafana.wikimedia.org/d/fd0c8c5e-3b26-4a90-bca2-a2504de1badc/mediawiki-and-centralauth-sessions dashboard, and it looks like @Krinkle already started making use of the recording rules (for session reads metric: https://gerrit.wikimedia.org/r/c/operations/puppet/+/1233214).

Done!

In T417600#11629799, @Zabe wrote:

Random shot: @DAlangi_WMF could it be that you are working on a mac?

Maybe I'm missing something, but even for core, some of the maintenance scripts are not properly namespaced or made to follow PSR-4 at all. Take update.php for example, running php maintenance/run.php Update --wiki=metawiki works for me.

Spent some time testing this today, and below are my observations after creating an OAuth2 consumer with the "client credentials" grant:

(17/02/2026): A measure of code coverage report generated locally for this class:

We finally resolved this bug. Thank you, @Krinkle, for the code reviews and guidance.

1. Risky Patch! 🚂🔥

As copied from Gerrit (comment from @Tgr), it seems we'll need to tackle this differently.

There isn't any easy way to figure out how to update that user object with the data you read from the primary. Most likely you'll just suppress the CAS error and silently write outdated data.