FYI, that patch was created in January 2020, after the CSS Speech Module was retired in 2018 but before the CSS Speech Module Level 1 was created in March 2020. It wasn't merged until February 2022 because no one else cared (and I was gone from WMF) until someone wanted something in one of the other specs being added or updated there and someone noticed the old patch still lying around.

AnomieBOT is working now. Logs seem to indicate it was fixed sometime after 2023-03-11 04:38:20.

The other two tools I have access to, oauth-hello-world (s51319) and mediawiki-mirror (s52152), both can connect with sql enwiki.

With some help from @bd808 I was able to get the webservice switched over, although I had to disable one feature (status page checking that the pod hadn't gone missing) due to lack of permission to access the Kubernetes API (specifically https://kubernetes.default.svc/api/v1/namespaces/$NAMESPACE/pods/) from inside the container. He said he'd file the Phab task or whatever to have someone look into that.

I think I have the bot's actual jobs all switched over. We'll see if anything blows up.

In T320830#8317655, @JJMC89 wrote:

https://k8s-status.toolforge.org/namespaces/tool-anomiebot/ has quota information and a link to Grafana.

Thanks. It may be a bit before I can check, as I'll also need T320824 to begin.

I did just find a case that updates it incorrectly: viewing an old viewed revision for some reason marks everything as viewed.

All I can say to that is that it still works fine on my local test wiki, diffs in particularly work as I described.

Finally got sick of seeing this and took 20 minutes to look into it (and then found this existing task about it). Looks like the problem was b33524cc93ee3e1a31c045f3c2f934ddaf9c186d, which incorrectly changed the global-ish baseRequestParams into a local variable so it's no longer preserved as intended across calls.

Correct, that's not what the sniff does. But this is what you said.

Perhaps you should search for instances of assertNotTrue or assertNotFalse as well, since your position is that those should never be used.

I'd think it would be unlikely for someone to use assertNotEquals or assertNotSame with a boolean and not intend for the behavior of assertNotTrue/assertNotFalse, otherwise they'd most likely have written it with assertEquals or assertSame and the opposite boolean in the first place.

I don't believe @Anomie has been very active as a volunteer lately, but I'd imagine they would have some relevant guidance to offer on this matter.

I note that the sniffs themselves don't actually require sebastian/diff, its only the Gerrit-specific report formatter that does. To better support reuse of the sniffs by third parties, you might consider moving that report formatter to a different repo so those of us who don't need it don't have to be constrained by its dependencies.

In T274050#6861287, @Cyberpower678 wrote:

Pinging @Anomie

Another option might be to make the trait stuff protected rather than private, so we can subclass the relevant tests and override them.

In T132676#6575067, @Mpaa wrote:

@Anomie is base64 encode supported by api action=upload?

Thanks! I'll resubscribe myself now to the ones I just filed, and any I happen to decide to pay attention to in the future.

All of them, please.

I don't have any new ideas, T220353#6045847 is a good summary.

update.php is supposed to have run maintenance/migrateComments.php to populate that data. That would have happened at any time with MediaWiki 1.30 if you set $wgCommentTableSchemaMigrationStage to a stage indicating that the comment table should be used, or in 1.33 if you never set $wgCommentTableSchemaMigrationStage to such a stage.

You said in T245310#5991274 that you weren't sure if you were supposed to move it out of CPT's "icebox" when a patch needed review, I was telling you that you can and should.

Next step is to determine the limits and implement them for Wikimedia sites in a patch similar to rOMWC8274bc4f3b29: Add PoolCounter configuration for Special:Contributions.

In T248003#6042819, @Nikerabbit wrote:

["D",1,false,[],[],[[[{},"cancelOnRollback"],"SMW\\MediaWiki\\Deferred\\TransactionalCallableUpdate::__construct",null],[[{},"cancelOnRollback"],"SMW\\MediaWiki\\Deferred\\TransactionalCallableUpdate::__construct",null]],[]]

[...]
Searching for cancelOnRollback results multiple hits in MediaWiki core and in SMW, but I assume it would be the one in TransactionalCallableUpdate.

In T249526#6042873, @Reedy wrote:

Should we be backporting this?

In T189769#6042901, @TheDJ wrote:

@Anomie question, why is frame:: extensionTag expensive