Azure-docs: Missing documentation for dynamic increment

[evertonmc]

This feature states to be "completed",
https://feedback.azure.com/forums/248703-api-management/suggestions/15161985-support-dynamic-n-for-quota-call-rate-limits
but there is no docs on how to achieve it

---

Document Details

⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

• ID: c64c31f4-ee3f-1482-14a8-3585ff5ef2de
• Version Independent ID: 8e50e224-bfd8-061c-3203-4d19016d16dd
• Content: Advanced request throttling with Azure API Management
• Content Source: articles/api-management/api-management-sample-flexible-throttling.md
• Service: api-management
• GitHub Login: @vladvino
• Microsoft Alias: apimpm

[PramodValavala-MSFT]

@evertonmc The quota policy supports a bandwidth attribute which defines

_"The maximum total number of kilobytes allowed during the time interval specified in the renewal-period"_

I believe this covers the scenario mentioned in the feature request.

[evertonmc]

It doesn't. The feature request refers to a custom N value for the increment, like: this requests costs 7 calls in the available quota.

[PramodValavala-MSFT]

@evertonmc My bad. Seems like I just read the part about the audio data.

@vladvino Do we support this?

[mike-urnun-msft]

Hi @miaojiang could you add some clarity to this?

[miaojiang]

@evertonmc can you please elaborate on your scenario? How do you determine the N?

[evertonmc]

@miaojiang in my case, N will be based on the request payload (object count) but in other usecases the request “weight” could be also part of the header or a jwt-claim

[miaojiang]

@evertonmc, got it. There is a 'increment-count' attribute you can use in the policy. Somehow it was removed from the documentation, we will add it back.

<rate-limit-by-key calls="number" renewal-period="seconds" 
    counter-key="expression like @(context.Subscription.Id) or a constant string"
    increment-count="optional, by default = 1"
/>

[evertonmc]

hi @miaojiang, thank you very much for revealing this (somehow) hidden attribute. It's exactly what we where looking for! Cheers!
I just tested this feature and it has a MAJOR bug, but I don't think that it belongs to the scope of this doc issue.

When increment-count is set in the quota-by-key policy and the (to-be-)incremented value exceeds the quota, the requests gets through once anyways. Which is probably by design, because incrementation happens after "response condition".
The problem is: Once this value get over the quota (lets say 101 for a quota of 100) it gets stuck at 403 quota exceeded, even if I reset the quota through the REST API

So the question is: Would you point me to the right place to submit this bug to?

[miaojiang]

@evertonmc we will take a look. Would be great if you can submit a support ticket to properly track the issue.

[mike-urnun-msft]

@evertonmc Since the discussion is now outside the scope of this documentation, we will now proceed to close this thread. If there are further questions regarding this matter, please reopen it and we will gladly continue the discussion.

[evertonmc]

@miaojiang I will. Thanks

[PramodValavala-MSFT]

@evertonmc Reopening this issue for tracking updates to this doc with respect to the insights shared here.

Also, feel free to open a similar issue on the reference doc as well.

[georgewallace]

@miaojiang Were you able to get the example you referenced above added to the document? Happy to add it if you can tell me which section it should go in.