Looks to be caused by:

1. PopulateCheckUserTablesWithSimulatedDataTest calls createRegisteredUser to test it
2. That method generates a registered username and causes an autocreation for that username
3. That causes IPReputationHooks::onLocalUserCreated to be called
4. That tries to make a request to the IPoid service (which does not exist in CI)
5. That request fails because the request was tried using a NullHttpRequestFactory.

Causing errors on wmf.26. Making a train blocker as this has been reported by CUs when trying to make range checks - Relevant errors are at https://logstash.wikimedia.org/goto/af8db930269e4a62ad5ef4e7e2214186

The proposed idea is to do the following:

1. On Special:Investigate provide two block buttons, one for accounts and one for IPs. This means that the CU can use two different forms to block users and IPs without having to manually remove either the users or IPs for a particular use of the form.
2. This would also be done for Special:CheckUser 'Get users', by replacing the form with links to Special:InvestigateBlock with one for all users and one for all IPs. This would implement T329493: Replace Special:CheckUser's 'get users' block form with a usage of Special:InvestigateBlock
   1. Doing this means that we have one form for mass blocking users in CheckUser, which makes implementing feature requests related to it easier. Currently we have to modify two different forms (one for CheckUser and one for Investigate). This means that
   2. The InvestigateBlock form has more features and is easier to use. There are several issues with the 'Get users' block form, such as T314700: Restore the bottom paging links on 'Get users' and that submitting the form causes the CU to need to re-load the 'Get users' request, which links to Special:InvestigateBlock that prefill the targets would not bring.
3. We may warn if the user attempts to use Special:InvestigateBlock for both IPs and users.

The team will be taking a look at this next week.

This should be done now based on T330158: Enable write new for the event table migration being complete.

For QA I would suggest suppressing a variety of information about log events and see if the information for these log events still displays in the CheckUser API.

Going to mark this as resolved, because all the logs I've seen in logstash have been addressed. The entries should reduce down to nothing once wmf.26 is out on all wikis.

Suggested QA steps for a local wiki:

1. Perform a infinite global block on an IP address
2. Perform a infinite global block on an account
3. Locally disable the global blocks performed in steps 1 and 2
4. Remove the global blocks performed in steps 1 and 2
5. Re-block the same IP address as you blocked in step 1 with a global block with that is not indefinite
6. Run the fixGlobalBlockWhitelist.php script with the --delete option included specified
7. Open Special:GlobalBlockList and verify that the global block on the IP address is marked as disabled
8. Open the database for the local wiki
9. Run SELECT gbw_expiry from global_block_whitelist where gbw_address = <IP>; replacing <IP> with the IP address you blocked in step 5
10. Verify that returned value is not indefinite and also matches the expiry you specified when you performed the global block in step 5
11. Run SELECT COUNT(*) from global_block_whitelist where gbw_address = <username>; replacing <username> with the username of the account you blocked in step 2 and verify that the result is 0.

Suggested QA steps for local wiki or patch demo:

1. Install CheckUser
2. Enable temporary account autocreation
3. Make an edit while logged out (which should also create a temporary account for you)
4. Note down the username of this temporary account
5. Log into an account with the checkuser user group
6. Find the edit made by the temporary account and press Show IP
7. Load Special:Contributions for the IP address that was displayed in step 6
8. Verify that the edit by the temporary account performed in step 3 appears in the contributions list, including that the username of the temporary account that made the edit is shown. For example, it should look like the following:

9. Load Special:Contributions for the IP address that was displayed in step 6 while logged out and verify that the edit performed by the temporary account in step 3 is not shown.

This will be QA'd through T361866: Display contributions from temporary accounts on Special:Contributions/IP.

Ideally I wanted it to still be true for the master branch.