Page MenuHomePhabricator

Sporadic issues with IP blocks on Russian Wikipedia - issue 1
Closed, ResolvedPublicBUG REPORT

Description

Since a couple of weeks, we are getting sporadic issues with IP blocks on the Russian Wikipedia.
I'm not sure if they are related to each other, so I'm creating multiple tickets - one for each issue type.

Steps to replicate the issue:

  • Hard to replicate, as the issue is sporadic.
  • Block enough IP addresses

What happens?:
The IP 2A00:1FA0:48A:6BCB:7F90:1290:197D:C7DD was blocked for one day on March 17th.
Two days later, the one day block seems to be still active.
https://ru.wikipedia.org/wiki/Служебная:Вклад/2A00:1FA0:48A:6BCB:7F90:1290:197D:C7DD

But if we take a look at the block log, we see another block of 3 days (made by other admin), but not the one-day block, which is displayed on the IP's contributions page (first link)
https://ru.wikipedia.org/w/index.php?title=Служебная:Журналы/block&page=Участник%3A2A00%3A1FA0%3A48A%3A6BCB%3A7F90%3A1290%3A197D%3AC7DD&uselang=en

What should have happened instead?:
The correct block (of 3 days) should be displayed instead of a one-day block, which has already expired two days ago.

Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):

Other information (browser name/version, screenshots, etc.):
I assume that the issue is related with the new "multi-block" feature being introduced. But it is not activated on RuWiki.

contribution_page.png (592×974 px, 251 KB)

block_log.png (841×1 px, 165 KB)

Details

Other Assignee
tstarling

Event Timeline

Aklapper renamed this task from Sporadic issues with IP blocks on the Russian Wikipedia - ISSUE 1 to Sporadic issues with IP blocks on Russian Wikipedia - issue 1.Mar 19 2025, 12:03 PM
Aklapper added a project: MediaWiki-Blocks.

I think what is happening here:

There are 3 blocks, but it is hard to see them all in the same place:

ru_investigation.png (144×1 px, 73 KB)

  • One is against 2a00:1fa0:48a:6bcb:7f90:1290:197d:c7dd (which hasn't expired) see block log and Special:BlockList
  • Two are against 2a00:1fa0:48a:6bcb::/64
    • one has expired, see block log
    • the second is not displayed normalised in the log, instead showing as 2a00:1fa0:48a:6bcb:7f90:1290:197d:c7dd/64. I cannot search for this in Special:Log but it can be searched for in the Special:BlockList. I am assuming that this was created via the API (the user has "bot" in their name so that makes sense) before the fix for T388097 was on production, and so the target was not properly normalised.

When you look at the contributions for 2A00:1FA0:48A:6BCB:7F90:1290:197D:C7DD it does a search in the logs for 2a00:1fa0:48a:6bcb::/64 which will only return the block log for the first (expired) block. It will only show the latest block log it can find.

After T388097, the API will normalise what gets stored in block_target.log_address and logging.log_title. However, I don't think we have considered whether we should clean up non-normalised data which is already in the database. @tstarling? I think at the moment, range blocks created via the API which passed non-normalised targets cannot be removed via Special:Unblock.

I think what is happening here:

There are 3 blocks, but it is hard to see them all in the same place:

ru_investigation.png (144×1 px, 73 KB)

  • One is against 2a00:1fa0:48a:6bcb:7f90:1290:197d:c7dd (which hasn't expired) see block log and Special:BlockList
  • Two are against 2a00:1fa0:48a:6bcb::/64
    • one has expired, see block log
    • the second is not displayed normalised in the log, instead showing as 2a00:1fa0:48a:6bcb:7f90:1290:197d:c7dd/64. I cannot search for this in Special:Log but it can be searched for in the Special:BlockList. I am assuming that this was created via the API (the user has "bot" in their name so that makes sense) before the fix for T388097 was on production, and so the target was not properly normalised.

When you look at the contributions for 2A00:1FA0:48A:6BCB:7F90:1290:197D:C7DD it does a search in the logs for 2a00:1fa0:48a:6bcb::/64 which will only return the block log for the first (expired) block. It will only show the latest block log it can find.

After T388097, the API will normalise what gets stored in block_target.log_address and logging.log_title. However, I don't think we have considered whether we should clean up non-normalised data which is already in the database. @tstarling? I think at the moment, range blocks created via the API which passed non-normalised targets cannot be removed via Special:Unblock.

It seems like normalising the IP addresses in block_target would also help solve T373847: IP addresses at dewiki that cannot be unblocked.

Dreamy_Jazz assigned this task to tstarling.

Seems to no longer be blocked.