Repository navigation
RETRY_AFTER is null in Lease object in case of SlidingWindow rate limiter #131175
Description
Is there an existing issue for this?
- I have searched the existing issues
Describe the bug
According to the documentation:
retryAfter can be used with the TokenBucketRateLimiter, FixedWindowLimiter, and SlidingWindowLimiter because these algorithms are able to estimate when more permits will be added.
However, when I use a SlidingWindowLimiter, the RETRY_AFTER metadata is null in the lease object.
The RETRY_AFTER metadata name is present in the MetadataNames enumerable, but the _retryAfter field behind it is null.
Register the rate limiter:
rateLimiterOptions.AddSlidingWindowLimiter("rateLimiterName", options =>
{
options.PermitLimit = rateLimiterConfiguration.PermitLimit;
options.Window = TimeSpan.FromSeconds(rateLimiterConfiguration.TimeWindowInSeconds);
options.QueueProcessingOrder = QueueProcessingOrder.OldestFirst;
options.SegmentsPerWindow = 10;
});
Read the RETRY_AFTER:
rateLimiterOptions.OnRejected = (context, cancellationToken) =>
{
if (context.Lease.TryGetMetadata(MetadataName.RetryAfter, out var retryAfter))
{
context.HttpContext.Response.Headers.RetryAfter =
((int)retryAfter.TotalSeconds).ToString(NumberFormatInfo.InvariantInfo);
}
};
Expected Behavior
On SlidingWindowLease object, _retryAfter field should be estimated and populated.
Steps To Reproduce
Exceptions (if any)
No response
.NET Version
net7.0, net8.0
Anything else?
No response
Reacted by tjwolfe, Paul Simkins, Valentin Vadász, Stone_Red, Pablo Moleri, ddimitrov9405, Soroush Kavousi, lonix1, Martin Costello, Deathwrap and 11 more
Activity
[-]RETRY_AFTER is null on Lease object in case of SlidingWindow rate limiter[/-][+]RETRY_AFTER is null in Lease object in case of SlidingWindow rate limiter[/+]lonix1 commentedon Oct 18, 2024
Agreed: this is bug, and also is documented incorrectly.
Without the retry property, the sliding window limiter is effectively useless in most use cases.
Can someone please label it as a bug, as it seems to have been forgotten?
Also, could it be fixed for v9?
sandeep-vemula commentedon Feb 22, 2025
seems, this is still not fixed. Anyone able to find any workaround on this or any alternate package?
thomotron commentedon Aug 21, 2025
I ran into this issue today as well.
Looking at the rate limiter itself it seems that the
SlidingWindowLease, despite having a constructor which accepts the retry afterTimeSpan, is never actually given a value for it. The lease acquisition process uses two static lease instances which are created with a null timespan.If this is truly not supposed to be implemented then the documentation ought to be updated to reflect that, but the fact
SlidingWindowLeasehas a constructor explicitly defined to accept aTimeSpansuggests otherwise.dotnet-policy-service commentedon Jul 21, 2026
Tagging subscribers to this area: @JulieLeeMSFT, @VSadov
See info in area-owners.md if you want to be subscribed.
BrennanConroy commentedon Jul 21, 2026
I think this was just an oversight. If someone is interested in fixing this feel free to open a PR and ping me for review. I assume we'll be able to copy from
FixedWindowLimiter.nwoolls commentedon Jul 22, 2026
@BrennanConroy ping - I've staged a PR that seems to address this oversight.
Populate RetryAfter on SlidingWindowRateLimiter
Populate RetryAfter on SlidingWindowRateLimiter (#131225)