Also see T304482.

Na, that's not the new column.

https://sal.toolforge.org/log/fBjnqoEB8Fs0LHO5zKRW

We had more than a million of these in the last hour.

In T305300#8028508, @Ladsgroup wrote:

FWIW I rebuilt all cloud views everywhere.

Support. I would also like to point out that this gerrit -1 query is not very meaningful, as it only shows the patches that currently have a -1 from Dreamy, but not the ones he gave -1's to in the past.

It seems like nothing is left to do here.

In T310884#8017744, @Dzahn wrote:

@Zabe Curious why those tickets start with a custom policy in the first place. Is that something we should try to change in the bot creating those?

I see no task associated with it and no discussion about it.

Btw. members of wmf-supportsafety are already capable of doing this due to them having userrights-interwiki, is that not sufficient?

This doesn't sound good to me. While testwiki is there for testing purposes, there are valid suppressions happening there, e.g. due to users accidentally editing while being logged-out.

@sbassett I see that @Dsharpe has been offboarded. Is there someone else I can ask now?

But OutputPage::setPageTitle() calls Sanitizer::removeSomeTags, is that not enough?

In T233004#7981926, @dom_walden wrote:

In T233004#7975137, @Zabe wrote:

In T233004#7972925, @dom_walden wrote:

@Zabe On my local machine, running php maintenance/update.php:
...

Huh, I can't reproduce and I also don't understand why it is happening. Which RDBMS are you using?

sqlite3, using docker.

@Dsharpe could I get access to T274514, the same issue seems to have reappeared at T309943? Could I also get access to T167219 and T244511, which are related to T224059?

I guess you mixed up the patch number, 803371 is a core patch.

In T309413#7985917, @hashar wrote:

deployment-parsoid12 went out of memory this morning which I have filed as T310069. It might be a duplicate or a different issue ;)

Could you (or someone else) add me to that task?

In T305890#7878052, @sbassett wrote:

In T305890#7865473, @DannyS712 wrote:

What about using a herald rule with a custom action:

• the first time #acl_security_volunteers is added to the task
• change the visibility policy: allow members of #acl_security_volunteers to view the task

This would not fight phab as much, since the actual presence of the tag doesn't affect the visibility, its just the herald rule

Or, without needing a custom action, just add the members of the acl as subscribers

I think this would mostly work, if it's a much easier solution to implement. The only issue I see is that if someone mistakenly or maliciously removes the acl (or users subbed to the task via the herald rule) then it would likely be difficult to notice that and they would just remain unaware of the protected task. That's not that terrible of an issue though, IMO.

In T309974#7982522, @Nikerabbit wrote:

For clarity, there wasn't any sort of response when I filed the bug. I guess it started responding with error afterwards, and then started working?

@Dsharpe could I get access to T309411?

There is a deeper problem with AbuseFilter sending data related to non-existent users to CheckUser (see T188180#7975147). CheckUser actor migration is basically stalled on fixing this. Let's stop writing to cuc_actor completly for now until we have a solution for that.

@Dsharpe could I get access to T280413?

abuse_filter_log saves non-existing users when AbuseFilter prevents account creation. This now make problems with the actor migration in checkuser, see T309737. Any ideas what we should do about that? It also basically makes actor migration for that table impossible in the current situation.

In T233004#7972925, @dom_walden wrote:

@Zabe On my local machine, running php maintenance/update.php:

Wikimedia\Rdbms\DBQueryError from line 1750 of /var/www/html/w/includes/libs/rdbms/database/Database.php: Error 1: no such column: cuc_actor
Function: MediaWiki\CheckUser\Maintenance\PopulateCucActor::doDBUpdates
Query: SELECT  cuc_id,cuc_user_text  FROM cu_changes    WHERE cuc_actor = 0 AND (cuc_id BETWEEN 5908 AND 6108)  

#0 /var/www/html/w/includes/libs/rdbms/database/Database.php(1734): Wikimedia\Rdbms\Database->getQueryException('no such column:...', 1, 'SELECT  cuc_id,...', 'MediaWiki\\Check...')
#1 /var/www/html/w/includes/libs/rdbms/database/Database.php(1708): Wikimedia\Rdbms\Database->getQueryExceptionAndLog('no such column:...', 1, 'SELECT  cuc_id,...', 'MediaWiki\\Check...')
#2 /var/www/html/w/includes/libs/rdbms/database/Database.php(1209): Wikimedia\Rdbms\Database->reportQueryError('no such column:...', 1, 'SELECT  cuc_id,...', 'MediaWiki\\Check...', false)
#3 /var/www/html/w/includes/libs/rdbms/database/Database.php(1954): Wikimedia\Rdbms\Database->query('SELECT  cuc_id,...', 'MediaWiki\\Check...', 32)
#4 /var/www/html/w/includes/libs/rdbms/database/DBConnRef.php(68): Wikimedia\Rdbms\Database->select('cu_changes', Array, Array, 'MediaWiki\\Check...')
#5 /var/www/html/w/includes/libs/rdbms/database/DBConnRef.php(277): Wikimedia\Rdbms\DBConnRef->__call('select', Array)
#6 /var/www/html/w/extensions/CheckUser/maintenance/populateCucActor.php(101): Wikimedia\Rdbms\DBConnRef->select('cu_changes', Array, Array, 'MediaWiki\\Check...')
#7 /var/www/html/w/maintenance/includes/LoggedUpdateMaintenance.php(45): MediaWiki\CheckUser\Maintenance\PopulateCucActor->doDBUpdates()
#8 /var/www/html/w/maintenance/update.php(205): LoggedUpdateMaintenance->execute()
#9 /var/www/html/w/maintenance/includes/MaintenanceRunner.php(195): UpdateMediaWiki->execute()
#10 /var/www/html/w/maintenance/doMaintenance.php(85): MediaWiki\Maintenance\MaintenanceRunner->run()
#11 /var/www/html/w/maintenance/update.php(264): require_once('/var/www/html/w...')
#12 {main}

(I also ran it with --force but got the same error.)

CheckUser version 2.5 (e924e27) 06:20, 1 June 2022.

In T307738#7963832, @Ladsgroup wrote:

What about renames? It can possibly make such changes.

LiquidThread still selects that column, now causing fatals: T309460.

FTR, it seems like beta-update-databases-eqiad was running out of memory while trying to perform the migration added in https://gerrit.wikimedia.org/r/c/mediawiki/extensions/WikiLambda/+/798987. I manually ran the migration script (sal), hopefully that fixed it.

The error showed up at enwiki, where we are not yet writing to cuc_actor (and thus it should also not write to the actor table), thus I can't see how it could be the checkuser changes.

In T309151#7954885, @Tacsipacsi wrote:

Do you have example rev_ids? I just successfully loaded the translation aids (including the edit summaries) for a random translation unit on mediawiki.org, so it’s not totally broken. Maybe the broken revisions have something in common.

~35 instances in the last 15 minutes, tagging as a blocker for now.