Added DBA for initial feedback. This is not likely to be planned in the short term. We would likely wait until both T361139 and T324907 are completed to reduce the issues caused by parallel database changes.

Moving back to Needs Review while the above fix is being reviewed.

I can reproduce this when not in limited width mode of Vector 2022. Looking into a fix.

I cannot see any of these warnings for 1.43.0-wmf.2 on the new errors dashboard. We could wait until 1.43.0-wmf.2 is on group2 before resolving this just in case there are still some that only occur on group2 wikis? However, I'd be happy to close this now.

In T318458#9743648, @dom_walden wrote:

@Dreamy_Jazz On Vector and Vector 2022 the text input does not appear below the dropdown:

That's strange. I was testing using Vector 2022 on my local wiki and it was below the drop down menu.

Thanks for the QA.

Suggested QA steps:

1. Open Special:Investigate while logged into an account with the checkuser and sysop groups
2. Enter some testing targets and run the check
3. Exclude at least one IP and user from the results (use Filter from the results in the dropdown menu). This button is shown below:

4. Verify that the subtitle of the results page looks has two buttons to block, one for IPs and the other for accounts:

5. Click on the Block accounts button and verify that only the accounts marked as targets in the investigation are included in the list of users, such as the following:

6. Verify that the user you filtered out in step 3 appears as an option you can select if you click in the usernames input shown in the screenshot above.
7. Click Continue and verify that the accounts listed in the usernames input are pre-filled in the Special:InvestigateBlock form and that this opened in a new tab
8. Repeat steps 5 to 7, but press Block IPs and verify that only the IPs marked as targets in the investigation are included in the usernames input.

Suggested QA steps:

1. Load Special:InvestigateBlock while logged in to a user with the checkuser and sysop groups
2. Verify that a dropdown menu appears under the Reason section along with a text input
3. Select an option from this dropdown
4. Verify that the * icon disappears from the text input
5. Select the Other option
6. Verify that the * icon re-appears in the text input
7. Select an option from the dropdown
8. Put some text in the text input
9. Enter some testing targets and use the form to block a user
10. Verify that the reason is the option from the dropdown combined with the reason you entered

Another example where the failure for the first patchset occurred after the third had been uploaded for at least 7 or so minutes: https://gerrit.wikimedia.org/r/c/mediawiki/extensions/CheckUser/+/1023890/3

In T356524#9739623, @Dreamy_Jazz wrote:

Some situations I can think of:

1. Within an hour or so of deployment to a wiki, there is some emergency situation that necessitates the need to shut-off temporary accounts and go back to the status quo

We should have a way to still allow the status quo (of IP editing) if the shutoff needed to be used a few hours after deployment.

Some situations I can think of:

1. Within an hour or so of deployment to a wiki, there is some emergency situation that necessitates the need to shut-off temporary accounts and go back to the status quo
2. Weeks after deployment, there is some mergency situation that necessitates the need to shut-off temporary accounts temporarily while a fix is implemented.
3. A community RfC rejects temporary accounts, and either
   1. They then want IP editing turned back on
   2. They want to force users to create an account
4. Too many temporary accounts are being created and DBA is concerned about the size of the user table (or related tables in the centralauth DB) growing out of control
5. Too many visitors are logged into a temporary account, and caching differences between temporary accounts and IPs cause increased server lag.
6. A coordinated mass attack using temporary accounts (i.e. clearing cookies and then changing IPs) is occurring, which leads to too many distinct users performing vandalism.

Going to decline this in favour of removing the integration as planned by @tstarling in T345052. If we don't do this, then any wiki which continues to use the data from CheckUser will have less data about recent logins but it won't break outright.

Reverting that patch though would cause TransactionProfiler warnings that were incorrectly made (i.e. the module requires post), so I thought that fixing the problem in ApiMain was better than reverting in ApiQuery.

In T363133#9737196, @Umherirrender wrote:

ApiQuery::isWriteMode is not that old, it is from eabb13833f8237bcd1ea89c8e0834da8d9ccf9f1 / T361951

Yes. This was the cause of this.

Thanks for the thorough QA testing.