I think we have no realistic way forward here. See T13201 for related things which are moving forward.

I don't currently plan to make "Disable User" any more granular than it is. If you have a use case where you want multiple administrator levels and to allow administrators at a certain level to act downward but not upward, you might be able to do something like have an enforcer-bot account which users can instruct to disable one another. The enforcer-bot itself could act via the API.

In T9041#240610, @epriestley wrote:

"Disable User", specifically, is now granular.

Use cases we've seen FWIW:

• This feature was originally added in D1378.
• This feature was accidentally broken by D11169.
• In D19661, I removed the nonfunctional remnants of D1378.

I wrote a patch for this, for both new log prototype and old log viewer here some screenshots for the view. If it is look OK, I will submit it.

This is now live.

Deploying the changes to web now.

I've issued all instances a 24-hour service credit for the disruption. This should be reflected on your next invoice.

Here's the request rate leading up to the rate limiting:

D19653 (above) changes the per-"Host" rate limit to require "X-Forwarded-For" be present in the request. This should exempt ELB requests from these limits.

... in production today as a next step.

This should have the pleasant side effect of letting us drop the goofy hard-coded internal rate limiting IP list.

There are four rate limits, and I don't currently have enough information to figure out which one triggered. The rate limits are:

The remaining work on the audit constants is:

See also PHI862 for a request for arc amend --force.

See PHI860 and T13111. In the future, repository nodes may automatically gc/prune/repack. If they do, it may make sense to sort them to the bottom of the list so traffic is sent to them only if no other nodes are available, in order to minimize the impact that gc/prune/repack have on other activity.

PHI860 is a close variant of this and discusses periodically running git repack. Most concerns around git repack are likely similar to concerns around gc and prune.

D19637 doesn't actually improve this, but it brings us a step closer (since the logic is now in PHP and can be modified more easily to label symbols and add context).