Change Details

The root cause of T260485 has been around for about a year, leading to several hundred blocks across wikis that are invisible and/or cannot be undone. There are two cases to consider: * A row exists in the local actor table with an id that matches the ipb_by_actor field, but it's referring to the wrong user. In this case, the block is mis-attributed, but functional. It's unclear how to detect this case. * No row exists in the local actor table with an id that matches the ipb_by_actor field, rendering the block entry defunct. This is easy to detect. A quick spot check find 20 such entries on dewiki and 96 on enwiki, around 2019-09-19. We could try to find an entry in the ipblocks table on meta with the same ipb_address value, and a close-by value of ipb_timestamp. But given the small number of cases and the limited relevance of the information, it may be easiest to just attribute such blocks to a reserved user, probably "Unknown user". So, we need to write a script that finds rows with bad values in ipb_by_actor, and replaces that value with the actor id of "Unknown user". This script needs to be run against all wikis. Given that the relevant query runs in under 2 seconds for enwiki and yields fewer than 100 rows to update, this should be quick and easy.

The root cause of T260485 has been around for about a year, leading to several hundred blocks across wikis that are invisible and/or cannot be undone. There are two cases to consider: * A row exists in the local actor table with an id that matches the ipb_by_actor field, but it's referring to the wrong user. In this case, the block is mis-attributed, but functional. It's unclear how to detect this case, see {T261143}. * No row exists in the local actor table with an id that matches the ipb_by_actor field, rendering the block entry defunct. This is easy to detect. A quick spot check find 20 such entries on dewiki and 96 on enwiki, around 2019-09-19. We could try to find an entry in the ipblocks table on meta with the same ipb_address value, and a close-by value of ipb_timestamp. But given the small number of cases and the limited relevance of the information, it may be easiest to just attribute such blocks to a reserved user, probably "Unknown user". We can leave fixing the block's attribution for later, see T261143. So for now, we need to write a script that finds rows with bad values in ipb_by_actor, and replaces that value with the actor id of "Unknown user". This script needs to be run against all wikis. Given that the relevant query runs in under 2 seconds for enwiki and yields fewer than 100 rows to update, this should be quick and easy.

The root cause of T260485 has been around for about a year, leading to several hundred blocks across wikis that are invisible and/or cannot be undone. There are two cases to consider: * A row exists in the local actor table with an id that matches the ipb_by_actor field, but it's referring to the wrong user. In this case, the block is mis-attributed, but functional. It's unclear how to detect this case, see {T261143}. * No row exists in the local actor table with an id that matches the ipb_by_actor field, rendering the block entry defunct. This is easy to detect. A quick spot check find 20 such entries on dewiki and 96 on enwiki, around 2019-09-19. We could try to find an entry in the ipblocks table on meta with the same ipb_address value, and a close-by value of ipb_timestamp. But given the small number of cases and the limited relevance of the information, it may be easiest to just attribute such blocks to a reserved user, probably "Unknown user". We can leave fixing the block's attribution for later, see T261143. So for now, we need to write a script that finds rows with bad values in ipb_by_actor, and replaces that value with the actor id of "Unknown user". This script needs to be run against all wikis. Given that the relevant query runs in under 2 seconds for enwiki and yields fewer than 100 rows to update, this should be quick and easy.