so let me try to explain why this happens. Every rename triggers lots of jobs tot be queued (and be eventually ran). The priority of these jobs is set to "low" as they are low priority comparing to for example cleanups after deletions (to avoid lingering private data around) and even if it takes an hour or so to finish, it shouldn't be a big deal. We can increase its priority or its concurrency but tbh we shouldn't. The reason you see this problem now and not a month ago is that we upgraded our jobrunners to new debian (buster) and it's slower as it has better security meaning we slowly are reaching our capacity (and adding capacity is not super easy). This will be hopefully get better but until then the global rename will be like the canary in a coal mine.

If it's really a big problem, let us know and we can bump its priority.