It look like the culprit is the time of the block. If you just change the settings, it changes just fine. See http://www.wikidata.org/w/index.php?title=Special:Log&page=User%3A186.233.104.1&type=block

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

[Resetting severity to normal, see http://www.mediawiki.org/wiki/Bugzilla/Fields#Severity ]

(In reply to comment #3)

[Resetting severity to normal, see
http://www.mediawiki.org/wiki/Bugzilla/Fields#Severity ]

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.

http://www.wikidata.org/w/index.php?title=Special:Log&type=block&page=User:46.118.124.27

http://www.wikidata.org/w/index.php?title=Special:Log&type=block&page=User:27.159.235.177

http://www.wikidata.org/w/index.php?title=Special:Log&type=block&page=User:190.52.124.38

Just a few recent examples. In all these cases two, not just one, "BLOCKED"'s showed up in pop-ups when mousing over them, as well as two entries in Special:BlockList.

(In reply to comment #6)

http://www.wikidata.org/w/index.php?title=Special:Log&type=block&page=User:46.118.124.27

From the Toolserver's wikidatawiki_p:

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

+----------+----------+------------+----------------+----------+---------------+---------------+---------------+----------+----------------------------+-------------------------------------------------+-------------+

nocreate | 0 |

anononly,nocreate | 0 |

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 https://www.wikidata.org/w/index.php?title=Special:Log&type=block&page=User:27.159.235.177 seemed to have worked just fine.)

http://p.defau.lt/?zwqWzA9XvamxrdVOZQlpGQ 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.