Consider filter cardinality in write ratelimiter for update-by-filter requests#5729
Consider filter cardinality in write ratelimiter for update-by-filter requests#5729
Conversation
| } | ||
| ) | ||
| assert response.status_code == 429 | ||
| assert "Rate limiting exceeded: Write rate limit exceeded, retry later" in response.json()['status']['error'] |
There was a problem hiding this comment.
Considering that we are assigning different rate limits to different operations, this information should be represented in the response error. Something like operation require X units, but Y availble, otherwise it would be confusing to debug
| } | ||
| } | ||
|
|
||
| pub fn filter(&self) -> Option<&Filter> { |
There was a problem hiding this comment.
We already have this
Which might be both: a better fit (cause also includes points, which we need to count as individual updates as well), and require some upgrade, cause we might not want to clone Filter
There was a problem hiding this comment.
This operation effect area is only used in ProxyShard, but ProxyShard itself is not used anywhere, so, if needed, we can change some stuff in the signatures if needed
agourlay
left a comment
agourlay
left a comment
There was a problem hiding this comment.
Nice cleanup on the clones 👍
* Consider filter-cardinality as cost in update ratelimiter * Use OperationEffectArea and improve rate limit error message * Clippy * Fix test
3 participants
No description provided.