Hi, I noticed that this user was blocked twice on meta-wiki, and the second block (2025-09-08T23:19:37Z UTC), almost simultaneous to the previous one (2025-09-08T23:19:35Z UTC), resulted in adding a new block to the previous one without any kind of warning.
The blocking admin confirmed that they had not received any notification or warning of the previous block that occurred 2 seconds before.
Thanks!
Since it is a common pattern (in addition, admins may mistakenly add a new block when their intention is to revoke talk page or email access), admins should be warned if they try to block a user that is already indefinitely blocked.
Yes fully agree, I'd say regardless of the duration of the previous block, a warning should appear saying "the user has already been blocked", also because in that case the admin can choose to change the block, add another one, or do nothing. I understand that this is a special case, since the blocks were almost simultaneous, but in medium-large wikis it often happens that conflicts arise between 2 or more sysops. Now, to be honest, I haven't had time to reproduce the situation on testwiki, but I'm sure that no warning or error message appeared (also due to the ~2 second timing).
Also, the log from Special:Contributions is not immediately helpful, the first block may not be seen if the admins don't notice "added a block for" instead of "blocked" and, if they are 2 different blocks, it can cause confusion.
What happened here is the second block had slightly different block settings, so the system didn't treat it as a block conflict. That as far as I can tell is the extent of block conflict logic in placing a new block when multiblocks is enabled.
I'd say regardless of the duration of the previous block, a warning should appear saying "the user has already been blocked", also because in that case the admin can choose to change the block, add another one, or do nothing
Yes, that sounds like the ideal behaviour. To make this viable, I suppose we'd need to introduce a timestamp-based conflict system, similar to starttimestamp parameter of the action=edit API. So when the block is actually placed, we check for any block that occurred since the starttimestamp that was given (which would be when the sysop open the Special:Block form).
I'm sure this is doable but it is a rather large chunk of work, I think. Adding Trust and Safety Product Team for them to triage. I do not believe Community Tech will have time to work on it in the near-term.
Also, the log from Special:Contributions is not immediately helpful, the first block may not be seen if the admins don't notice "added a block for" instead of "blocked" and, if they are 2 different blocks, it can cause confusion.
T393902: Multiblocks: Display only active blocks on the top of blocked user's Special:Contributions page / when editing a blocked user's user [talk] page should help with that, which will go live next week.