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
While experimenting with the AdaptiveRetryStrategy in @smithy/util-retry with Cognito's ListUsers API (which has a very low quota) I discovered that the updateClientSendingRate() method of DefaultRateLimiter never enables the rate limiter because the test to check if the response is a throttling error always returns false.
The issue is that updateClientSendingRate() considers that response argument is the SdkError and directly calls isThrottlingError(response), but AdaptiveRetryStrategy in @smithy/util-retry calls it with either a RetryErrorInfo or an empty object, and the RetryErrorInfo object has the SdkError in its error property. But actually there would be no need to call isThrottlingError(response) since the errorType property of RetryErrorInfo already has the necessary information.
However, the deprecated AdaptiveRetryStrategy in @smithy/middleware-retry seems to call updateClientSendingRate() with another object type, but I am not sure which one it is.
The following test program demonstrates the problem (replace the POOL_ID by a valid Cognito pool ID). with the FIX LINE commented out the requests are throttled but the state of the retry strategy at the end of the tests show that the rate limiter is not enabled, so the bucket capacity is never considered. Unccommenting the FIX LINE fixes the problem by overriding the argument passed to updateClientSendingRate() to be the SdkError object.
While experimenting with the
AdaptiveRetryStrategy
in@smithy/util-retry
with Cognito'sListUsers
API (which has a very low quota) I discovered that theupdateClientSendingRate()
method ofDefaultRateLimiter
never enables the rate limiter because the test to check if the response is a throttling error always returns false.The issue is that
updateClientSendingRate()
considers thatresponse
argument is theSdkError
and directly callsisThrottlingError(response)
, butAdaptiveRetryStrategy
in@smithy/util-retry
calls it with either aRetryErrorInfo
or an empty object, and theRetryErrorInfo
object has theSdkError
in itserror
property. But actually there would be no need to callisThrottlingError(response)
since theerrorType
property ofRetryErrorInfo
already has the necessary information.However, the deprecated
AdaptiveRetryStrategy
in@smithy/middleware-retry
seems to callupdateClientSendingRate()
with another object type, but I am not sure which one it is.The following test program demonstrates the problem (replace the POOL_ID by a valid Cognito pool ID). with the FIX LINE commented out the requests are throttled but the state of the retry strategy at the end of the tests show that the rate limiter is not enabled, so the bucket capacity is never considered. Unccommenting the FIX LINE fixes the problem by overriding the argument passed to
updateClientSendingRate()
to be theSdkError
object.The text was updated successfully, but these errors were encountered: