Global rename uses a database table (renameuser_status) to keep track of the state of a given rename in each wiki. The status can be queued (the rename job still needs to run), inprogress (the job is running right now) or failed (the local rename failed, should be retried or manually fixed). Successful renames are indicated by the row for that wiki being absent.

The inprogress status acts as a lock (the job will refuse to start if it sees that status). It is not a very good lock however, because it needs to be removed explicitly when the job finishes or fails; and while the fail handler tries to do that, it is possible for jobs to fail so hard that the fail handler isn't even invoked. (T402435: Jobs sometimes disappear without a trace (except "Exec error in cpjobqueue" / "Error: socket hang up" from change-propagation service) is a recently discovered example.) So the wiki gets stuck in inprogress (which means the user who is being renamed is locked out from that wiki) until manual intervention.

The status table is useful for human monitoring of the (sometimes slow) rename process, to recover from deterministic failures, and as long as the jobs are run in a daisy chain manner, it also serves as the way to determine which wiki to run on next. (Some time in the past the rename ran parallel on all wikis, but that caused frequent race conditions so rECAU053b4ce1e137: Make LocalRename jobs run sequentially changed them to run sequentially. There are probably better ways to avoid CAS errors; but that's beyond the scope of this task.) But the way to prevent multiple jobs from running should be via a lock, as that gets removed automatically if the running process dies. The jobs should then check the lock at startup, and do not bail on inprogress status if the wiki is not locked.