Why is RateLimiterMinimumCapacityLeft & SharePointRest.UseRetryAfterHeader off by default?

[rlv-dan]

My solution was getting throttled and I looked through the PnP settings. There I noticed that HttpRequests.RateLimiterMinimumCapacityLeft and HttpRequests.SharePointRest.UseRetryAfterHeader were both turned off by default. (Graph equivalent is on by default though.) Turning them both on seems to have solved my throttling problems. Great! But it makes me wonder why these are not on by default? Are there problems associated, or something we should be aware of when using these?

[jansenbe]

@rlv-dan : Rate limiting is turned off by default, but throttling handling using UseRetryAfterHeader is on by default (see https://github.com/pnp/pnpcore/blob/dev/src/sdk/PnP.Core/Services/Builder/Configuration/PnPCoreOptions.cs). We choose to not have rate limiting on by default as the capacity left value needs to be set based upon the usage, like in a multithreaded setup you want to set the value higher as there are more parallel requests.

[rlv-dan]

Oh, ok. The comment is wrong, it says it's false by default:

/// <summary>
/// Use the Retry-After header for calculating the delay in case of a retry. Defaults to false
/// </summary>
public bool UseRetryAfterHeader { get; set; } = true;

My 2 cents: I was seeing a lot of 429 errors in Application Insights. Adding RateLimiterMinimumCapacityLeft made these go away. I prefer not seeing errors by default, even there are mechanisms that automatically recovers. It's easier to expain to customers that it's actually not an error...

[jansenbe]

Thanks, I've fixed the comment. When you see a 429 in logs means your request got throttled and was retried...that is fine. With Rate Limiting your code an understand when it's about to get throttled and will slow down before, this will slightly increase the code's throughput