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
Upon receiving a 429 response along with X-RateLimit headers a client should obey those headers.
For instance, if X-RateLimit-Remaining header has 0 as its value, then a client should wait X-RateLimit-Reset seconds before making another retry.
However, when riptide clients are configured through riptide-spring-boot-autoconfigure in riptide 4.1.0, those headers get ignored.
This was not the case in Riptide 3.x.x
Expected Behavior
X-RateLimit headers are respected
Actual Behavior
X-RateLimit headers are ignored
Possible Fix
I am not sure but one possible reason is this change.
Riptide autoconfiguration creates a composite delay function, consisting of two functions: RetryAfterDelayFunction and RateLimitResetDelayFunction. When Retry-After is missing and the X-RateLimit headers are present it should take result of the RateLimitResetDelayFunction (see here). But since RetryAfterDelayFunction does not return null anymore, its result is taken (Duration.ofMinutes(-1)). Because it is a negative interval, retry happens immediately.
However, this is just a guess.
Steps to Reproduce
The following test works in Riptide 3.4.0 (with JDK 8) but does not work in the current main branch (JDK 17)
java.lang.AssertionError:
Expected: a value equal to or greater than <PT2S>
but: <PT0.084450105S> was less than <PT2S>
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
at org.zalando.riptide.autoconfigure.retry.XRateLimitResetRetryTest.shouldObeyXRateLimitHeader(XRateLimitResetRetryTest.java:74)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
Context
One of our tests started to fail when we migrated to Riptide 4.1.0 (4.0.0 seems to have the same problem).
The text was updated successfully, but these errors were encountered:
Description
Upon receiving a 429 response along with X-RateLimit headers a client should obey those headers.
For instance, if
X-RateLimit-Remaining
header has 0 as its value, then a client should waitX-RateLimit-Reset
seconds before making another retry.However, when riptide clients are configured through
riptide-spring-boot-autoconfigure
in riptide 4.1.0, those headers get ignored.This was not the case in Riptide 3.x.x
Expected Behavior
X-RateLimit headers are respected
Actual Behavior
X-RateLimit headers are ignored
Possible Fix
I am not sure but one possible reason is this change.
Riptide autoconfiguration creates a composite delay function, consisting of two functions:
RetryAfterDelayFunction
andRateLimitResetDelayFunction
. WhenRetry-After
is missing and theX-RateLimit
headers are present it should take result of theRateLimitResetDelayFunction
(see here). But sinceRetryAfterDelayFunction
does not return null anymore, its result is taken (Duration.ofMinutes(-1)
). Because it is a negative interval, retry happens immediately.However, this is just a guess.
Steps to Reproduce
The following test works in Riptide 3.4.0 (with JDK 8) but does not work in the current main branch (JDK 17)
Output for the current main:
Context
One of our tests started to fail when we migrated to Riptide 4.1.0 (4.0.0 seems to have the same problem).
The text was updated successfully, but these errors were encountered: