When we retry after a 429, we get another 429.
I suspect a round-down issue.
In our scenario:
we do requests, and eventually get a 429 Too Many Request with Retry-After: 19
we wait 19 seconds, then try again:
—> We get a 429 again, with Retry-After: 0
Now, can it be the actual values were 19.4 and 0.4 for example and they were rounded down for the Retry-After in the headers?
4개의 좋아요
Probably, should be an easy fix. Another starter task @erlend_sh ?
2개의 좋아요
dinomite
(Drew Stephens)
11월 28, 2018, 4:10오후
3
I’m not entirely sure where this is happening, but I suspect it has to do with use of Lua’s tonumber() in rate_limiter.rb —quoth Redis’ EVAL documentation :
Lua has a single numerical type, Lua numbers. There is no distinction between integers and floats. So we always convert Lua numbers into integer replies, removing the decimal part of the number if any.
4개의 좋아요
andrei
(Andrei Prigorshnev)
1월 11, 2021, 5:02오후
4
저는 이 버그를 처리하고 있으며, 내일 풀 리퀘스트를 제출할 예정입니다.
1개의 좋아요
andrei
(Andrei Prigorshnev)
1월 12, 2021, 4:52오후
5
결국 문제는 Lua 스크립트의 반올림이 아니었습니다. Lua 스크립트는 이미 반올림된 값을 받습니다.
더 나아가, 아예 반올림 문제가 아닙니다. 반올림되지 않은 초 단위가 사용되더라도, 여전히 Retry-After: 0과 함께 429 응답을 받을 수 있습니다.
주된 문제의 수정 사항은 다음과 같습니다:
master ← AndrewPrigorshnev:fix/sliding-window-end-time-in-rate-limiter
merged 06:26PM - 12 Jan 21 UTC
If the sliding window size is N seconds, then a moment at the Nth second should … be considered as the moment outside of the sliding window.
Otherwise, if the sliding window is already full, at the Nth second, a new call wouldn't be allowed, but a time to wait before the next call would be equal to zero, which is confusing.
In other words, the end of the time range shouldn't be included in the sliding window. Let's say we start at the second 0, and the sliding window size is 10 seconds. In the current version of Rate Limiter, this sliding window will be considered as a time range `[0, 10]` (including the end of the range), which actually is 11 seconds in length.
After this fix, the time range will be considered as `[0, 10)` (excluding the end of the range), which is exactly 10 seconds in length.
가끔 같은 오류를 유발할 수 있는 추가 문제의 수정 사항은 다음과 같습니다:
master ← AndrewPrigorshnev:fix/use-the-same-time-moment-in-redis-calls
merged 08:09PM - 12 Jan 21 UTC
3개의 좋아요