This is weird - multiblocks isn't supposed to be enabled in production yet but because of some race condition a user got blocked twice anyway: https://es.wikipedia.org/w/index.php?title=Especial:Registro&page=User%3AJaredlmns&type=block

The user isn't just blocked twice, they also have two block_target rows. That's supposed to be prevented by a gap lock acquired by the UPDATE query in acquireTarget(). I must have missed something.

Just a bad assumption I guess. Easily reproduced. An update on a non-existent row acquires an IX lock, which can be shared by a different thread. Actually writing to the row acquires an X lock. So both threads involved in the race can do the update, then the inserts are serialized.

Here are the queries involved, slightly simplified:

• UPDATE block_target SET bt_count=bt_count+1 WHERE bt_user=$user;
• INSERT INTO block_target (bt_user) VALUES ($user);
• COMMIT

With numbers indicating the thread executing the query, if the sequence is 1.update, 2.update, 1.insert, 2.insert, you get a deadlock error. If the sequence is 1.update, 1.insert, 2.update, 1.commit, 2.insert, you get two rows. If the 2.insert is issued after the 1.insert but before the 1.commit, it will wait for the other thread to commit and then succeed.

I think the schema is wrong, it needs a unique index. Then it's just an upsert. The only workaround I can think of is GET_LOCK() released in a transaction idle callback.

Subscribing @Ladsgroup and @aaron since they can at least understand what I'm talking about and commiserate.

Finding duplicate rows with

for w in $(expanddblist all); do sql $w -- -B --skip-column-names -e 'select group_concat(bt_id) from block_target where bt_user is not null group by bt_user having count(*) > 1; select group_concat(bt_id) from block_target where bt_address is not null group by bt_auto, bt_address having count(*) > 1;' | sed "s/^/$w /"; done

There are 75 such groups of rows, mostly close pairs of IDs, consistent with the race condition I described above. The task description relates to eswiki 568016,568023. However, in 15 cases, there is a duplicate between bt_id=1 and a much higher numbered bt_id, with the higher numbered one being an orphan row, with bt_count=1 but not connected to any block. So that's a separate bug.

I checked two of the bt_id=1 conflicts, and they were both created on 2024-02-29, around the time migrateBlocks.php was running. So that's a migration bug.

Change #1128056 had a related patch set uploaded (by Tim Starling; author: Tim Starling):

[mediawiki/core@master] block: Suppress exception when reblocking a multi-blocked user

https://gerrit.wikimedia.org/r/1128056

Change #1128063 had a related patch set uploaded (by Tim Starling; author: Tim Starling):

[mediawiki/core@master] block: Add cleanupBlocks.php

https://gerrit.wikimedia.org/r/1128063

Change #1128056 merged by jenkins-bot:

[mediawiki/core@master] block: Suppress exception when reblocking a multi-blocked user

https://gerrit.wikimedia.org/r/1128056

I split off the cleanup script to T389301 so that this task can be closed.

El T388743#10649907, @tstarling escribió:

I split off the cleanup script to T389301 so that this task can be closed.

Hi. I'm still unable to unblock user Jaredlmns at es.wikipedia. Can you tell me what ticket should I monitor?

@tstarling Is this LTS (1.43) backport worthy?

In T388743#10649916, @LuchoCR wrote:

Hi. I'm still unable to unblock user Jaredlmns at es.wikipedia. Can you tell me what ticket should I monitor?

Please try to unblock this user using the following two links:

• https://es.wikipedia.org/wiki/Especial:Bloquear/Jaredlmns?usecodex=1&remove=1&id=9205500
• https://es.wikipedia.org/wiki/Especial:Bloquear/Jaredlmns?usecodex=1&remove=1&id=9205507

In T388743#10650032, @Reedy wrote:

@tstarling Is this LTS (1.43) backport worthy?

The exception is from December (cf1198155c27e1cb4b02ec9ab01d91c0820f0667) so should not affect 1.43. Prior to December, attempting to unblock or reblock a user with a duplicate block should select a random block for the given target and act on that one block. So users should be able to resolve it by going to Special:Unblock twice.

I'll think about a backportable solution for the race condition. You know my favourite idea at T389028 requires an SQLite version bump so is probably not backportable.

El T388743#10650990, @tstarling escribió:

In T388743#10649916, @LuchoCR wrote:

Hi. I'm still unable to unblock user Jaredlmns at es.wikipedia. Can you tell me what ticket should I monitor?

Please try to unblock this user using the following two links:

• https://es.wikipedia.org/wiki/Especial:Bloquear/Jaredlmns?usecodex=1&remove=1&id=9205500
• https://es.wikipedia.org/wiki/Especial:Bloquear/Jaredlmns?usecodex=1&remove=1&id=9205507

Thank you! User is now unblock. Pura vida!

@tstarling Confirmed that the system does not throw a RuntimeException and does not allow reblocking as seen from the gif below. I will mark this as Resolved. Thanks for all your work!

Test Result - Local

Status: ✅ PASS
Environment: Local: MediaWiki- 1.44.0-alpha (af413e5) 13:51, 19 March 2025
OS: macOS Sequoia 15.4
Browser: Chrome 134
Device: MBA
Emulated Device: NA

Test Steps

Test Case 1: Verify that Special:Block does not throw a RuntimeException when reblocking a user with multiple existing blocks

1. Navigate to Special:Block on a wiki where multiblocks are enabled.
2. Enter a target user/IP and apply a first block.
3. Apply a second block on the same user/IP.
4. Attempt to reblock the same user/IP with a different expiration or block reason.
5. Turn off multiblocks and Codex Special:Block
6. Go to Special:Block again and try to reblock the same user
7. ✅ AC1: Confirm that the system does not throw a RuntimeException and does not allow reblocking. You should see an error that you cannot reblock

6. ✅ AC2: Confirm that the existing blocks are correctly updated or preserved without corruption.

See AC1