Page MenuHomePhabricator

Change of IP block settings produces duplicate block
Closed, ResolvedPublicJun 16 2020


In this block, Techman224 intended to change the settings of my original block, but instead created a duplicate block, as suggested by this log and Special:BlockList (not to mention pop-ups (i.e. via API)).

I have not seen this problem on any other wikis, but this problem has been present as early as December - (where the latest log entry saying that I made a block was really me trying to change the block settings)

Version: 1.22.0
Severity: normal


Due Date
Jun 16 2020, 4:00 AM

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:33 AM
bzimport set Reference to bz44657.
bzimport added a subscriber: Unknown Object (MLST).

It look like the culprit is the time of the block. If you just change the settings, it changes just fine. See

Can we please get this fixed? This problem has gone on for long enough.

(In reply to comment #3)

[Resetting severity to normal, see ]

I'm not sure how this isn't a "Major loss of function in an important area".

It's a major loss of function since every time two admins block the same vandal/spambot/etc one of them has to go back, manually undo two blocks, then re-block, and then revert/delete whatever the account did in the few sections it was unblocked for.

It's obviously an important area since we need to be able to stop vandalism and spammers and not have to redo a block that should have worked just fine in the first place.

More importantly this bug is important because no one else has reported it except on Wikidata. To the best of my knowledge, nothing in the Wikibase and related extensions should interfere with the blocking code, which means it might be a bigger problem.

I'm having a little difficulty following this bug. Are there actually duplicate blocks being saved to the database? Generally that should be prohibited. That is, there should only be one exact match for ipb_address (username or IP address) in ipblocks.

The underlying issue sounds something like "reblocks don't work properly with IP addresses," but it's difficult to say currently.

(In reply to comment #6)

From the Toolserver's wikidatawiki_p:

mysql> select * from logging_ts_alternative where log_namespace = 2 and log_title = '';



27988876blockblock201304202334503724Jasper Deng246.118.124.270spambot3 months

nocreate | 0 |

27989023blockblock201304202335043724Jasper Deng246.118.124.270spambotSat, 20 Jul 2013 23:34:50 GMT

anononly,nocreate | 0 |

27989395blockunblock201304202335443724Jasper Deng246.118.124.270resolving double-block bug0
27989469blockunblock201304202335523724Jasper Deng246.118.124.270resolving double-block bug0
27990113blockblock201304202336553724Jasper Deng246.118.124.270spambot3 months

anononly,nocreate | 0 |
5 rows in set (0.00 sec)

All three examples from comment 6 have been "corrected." Are there any live/living examples of this problem? (I'll also note that a subsequent reblock of seemed to have worked just fine.) is vaguely more legible.

Perhaps this has to do with adjusting block settings? Does every example of this problem involve changing block settings?

And how are these blocks being made? Via the API via a user script? Via the block form? Some other way?

The aforementioned blocks were made by hand using the on-wiki interface, and the problem always occurs for changes of block settings (not necessarily by the same admin - see previous comments).

From wikidatawiki_p:

mysql> select ipb_address, count(*) from ipblocks group by ipb_address having count(*) > 1 order by ipb_address;




8 rows in set (0.01 sec)

enwiki_p has 114 rows for the same query.

Does anyone have an idea what is special in Wikidata here that could cause this? Because I can't think of anything we're changing there.

I was able to reproduce this on Uncyclopedia (1.21.1), so moving to MediaWiki component.

Myself and another sysop blocked at nearly the exact same time with different block settings, causing duplicate blocks.

Thank you, @JJMC89. This is not a duplicate of T197108, which is part of the WMF's Anti-Harassment Tools team's project for Partial Blocks.

The problem appears to be that the unique index on ipblocks allows duplicate blocks with the same target but different anon-only settings. From tables.sql:

CREATE UNIQUE INDEX /*i*/ipb_address_unique ON /*_*/ipblocks (ipb_address(255), ipb_user, ipb_auto, ipb_anon_only);

There are no checks for uniqueness in the application layer, so the block is able to be inserted if there is no conflict.

That should be fixed in T251188 by removing anon_only from the index.

ARamirez_WMF changed the subtype of this task from "Task" to "Deadline".
ARamirez_WMF changed Due Date from Jun 2 2020, 4:00 AM to Jun 17 2020, 4:00 AM.Jun 9 2020, 5:25 PM
ARamirez_WMF changed Due Date from Jun 17 2020, 4:00 AM to Jun 16 2020, 4:00 AM.Jun 9 2020, 8:28 PM