You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would be used as a precaution against being accidentally overly-aggressive when setting new rate limits on existing systems.
It'd probably be useful if both real and check-only limits could co-exist for the same rate limit pattern, to help with testing whether it would be safe to lower an existing rate limit.
I'm imagining something like check_only_requests_per_unit or test_requests_per_unit that could be set side-by-side with or in place of requests_per_unit and increment a different metric name instead of the existing over-limit metric (and near-limit metric) when it would have triggered.
The text was updated successfully, but these errors were encountered:
@repl-david-winiarski This is exactly what we're looking for! Is there a reason for not merging your changes upstream? I think it would be very valuable
Would be used as a precaution against being accidentally overly-aggressive when setting new rate limits on existing systems.
It'd probably be useful if both real and check-only limits could co-exist for the same rate limit pattern, to help with testing whether it would be safe to lower an existing rate limit.
I'm imagining something like
check_only_requests_per_unit
ortest_requests_per_unit
that could be set side-by-side with or in place ofrequests_per_unit
and increment a different metric name instead of the existing over-limit metric (and near-limit metric) when it would have triggered.The text was updated successfully, but these errors were encountered: