Why:
- Setting the increment to 0 should check the limit without bumping it.
- This was apparently broken by If3e66491306f22650.
What:
- Use LimitBatch::peek if the increment amount is 0
Bug: T381033
Change-Id: Ife76a1976a2063f051f00302e5adaebd701e6367
(cherry picked from commit e09606b3dc44711571cc6cf2d0d11bd7784d0cdd)
Mostly used find-and-replace:
Find:
/\*[\*\s]+@var (I?[A-Z](\w+)(?:Interface)?)[\s\*]+/\s*(private|protected|public) (\$[a-z]\w+;\n)((?=\s*/\*[\*\s]+@var (I?[A-Z](\w+)(?:Interface)?))\n|)
Replace with:
\3 \1 \4
More could be done, but to keep this patch reasonably sized, I only
changed the most obvious and unambiguously correct cases.
In some cases, I also removed redundant doc comments on the
constructor, and re-ordered the properties to match the constructor.
Change-Id: I3f8427ae4f5d55177ae18986ef15d84d0e7bf6f4
According to the dictionary, "per" (or more conventionally "as per")
means "according to". Refer OED "per" sense II.3.a. For example:
"No value was passed, so return null, as per default".
In this sentence, we are not specifying the default, we are referring
to the default. This correct usage of "per default" was used nowhere
in MediaWiki core as far as I can see.
Instead we have "per default" being used to mean "by default", that is,
giving the value to use when no explicit value was specified.
In OED, the phrase "by default" is blessed with its own section just
for computing usage:
"P.1.e. Computing. As an option or setting adopted automatically by a
computer program whenever an alternative is not specified by the user
or programmer. Cf. sense I.7a."
There are highly similar pre-computing usages of the same phrase,
whereas the phrase "per default" is not mentioned.
As a matter of style, I think "per default" should not be used even
when it is strictly correct, since the common incorrect usage makes it
ambiguous and misleading.
Change-Id: Ibcccc65ead864d082677b472b34ff32ff41c60ae
Rate limits will automatically be checked by definitelyCan(),
authorizeRead() and authorizeWrite(). The authorize methods also
increment the counter.
UserAuthority tracks which limits have already been incremented during
the current request, to avoid duplicate increments caused by code that
still calls pingLimiter directly.
DEPLOY: Risky! We SHOULD not hit rate limits more often, but we might.
Rate limit metrics should be monitored closely, see
<https://grafana.wikimedia.org/d/8oA6CWr4z/mw-rate-limiting-overview>.
Bug: T310476
Depends-On: Iebd62b0487af9172edaeae41c9b31aaf2f20fd06
Change-Id: Ic349f03b7040343815b60b0a2c84a5780326c797
To prepare for changes to how, when and where we check rate limits,
we should start collecting statistics on how limits are checked and
enforced in production. This will alert us to unintended effects of
the refactoring. In addition, it provides information on the impact
each limit rule has.
Bug: T310476
Change-Id: I9dfbf3847b73ab5f145722c45b93056408ad9444
