Closed inconspicuous99 closed 2 years ago
The usage of until_n_ready
looks right - it's fallible because api_cost
could be greater than the rate limiter's burst capacity (e.g. trying to get 6 elements through a limiter that allows 5 elements per second), so unwrap()
or other error-handling methods are necessary. If the api cost fits into burst capacity, until_n_ready
will wait until the request can proceed.
The usage of check_n
needs more special-casing though: Since there are two possible Err cases (one, saying it's not ready yet, the other saying it can never be ready). I'd suggest something like (rust syntax not checked, sorry):
match ratelimit.check_n(api_cost) {
Ok(_) => (), // proceed
Err(NegativeMultiDecision::BatchNonConforming(_, not_until)) => ..., // We are blocked for now, but can retry later
Err(NegativeMultiDecision::InsufficientCapacity(_)) => panic!("Programming error: this API call can never succeed"),
}
Hope that helps - I'll close this issue, but if you need more help with the API, feel free to reopen.
this is the correct usage right?