Wikimedia Bugzilla is closed!

Hmm, I don't see how this could possibly happen. I assume you don't have any custom extensions hooking into PerformRetroactiveAutoblock ? (Nothing in the repo uses that hook, but thought i'd check)

Not as far as I know.

I couldn't reproduce it either.

$status = false;

> array_merge( array( $status['id'] ), $status['autoIds']  );

Warning: array_merge(): Argument #2 is not an array in /www/sandwiki/maintenance/eval.php(77) : eval()'d code on line 1

I should note that Special:Block has become very slow recently, often timing out.

Re-read the code. First time I read through I thought the part that checked if status was false returned in both branches of the if but it doesn't.

So it could happen if while in the process of re-blocking, someone inserts a block just after the old block was removed I think.

The delete() would block on the EX lock of the insert by the other process and then lock the index gap for the row in delete()...so the shouldn't the second insert() always work?

That said, the code should still check for this, since some people use MyISAM...which sucks for MW but whatever.

(In reply to comment #5)
> I should note that Special:Block has become very slow recently, often timing
> out.

This seems to be unrelated. On further inspection the POST request never arrives into lighttpd's access nor error log. Sigh. I hate computers.

(In reply to comment #7)
> That said, the code should still check for this, since some people use
> MyISAM...which sucks for MW but whatever.

FYI: twn is using InnoDb for almost all tables.

Assuming fixed, it's been a year and not seen this recently.