Merge pull request #292069 from nimakamoosi/nimak/fix/rate-limit-increment-expressions

fix(rate-limit) detail behavior change of increment attributes with expression

Author: prmerger-automator[bot]

articles/api-management/rate-limit-by-key-policy.md

@@ -44,9 +44,9 @@ To understand the difference between rate limits and quotas, [see Rate limits an
 | ------------------- | ----------------------------------------------------------------------------------------------------- | -------- | ------- |
 | calls               | The maximum total number of calls allowed for the key value during the time interval specified in the `renewal-period`. Policy expressions are allowed. | Yes      | N/A     |
 | counter-key         | The key to use for the rate limit policy. For each key value, a single counter is used for all scopes at which the policy is configured. Policy expressions are allowed.         | Yes      | N/A     |
-| increment-condition | The Boolean expression specifying if the request should be counted towards the rate (`true`). Policy expressions are allowed.        | No       | N/A     |
-| increment-count | The number by which the counter is increased per request. Policy expressions are allowed.       | No       | 1     |
-| renewal-period      | The length in seconds of the sliding window during which the number of allowed requests should not exceed the value specified in `calls`. Maximum allowed value: 300 seconds. Policy expressions are allowed.                | Yes      | N/A     |
+| increment-condition | The Boolean expression specifying if the request should be counted towards the rate (`true`). Policy expressions are allowed but will postpone evaluation and counter increment actions to end of outbound pipeline.        | No       | N/A     |
+| increment-count | The number by which the counter is increased per request. Policy expressions are allowed but will postpone evaluation and counter increment to end of outbound pipeline.       | No       | 1     |
+| renewal-period      | The length in seconds of the sliding window during which the number of allowed requests should not exceed the value specified in `calls`. Maximum allowed value: 300 seconds. Policy expressions are allowed.       | Yes      | N/A     |
 | retry-after-header-name    | The name of a custom response header whose value is the recommended retry interval in seconds after the specified call rate is exceeded for the key value. Policy expressions aren't allowed. |  No | `Retry-After`  |
 | retry-after-variable-name    | The name of a policy expression variable that stores the recommended retry interval in seconds after the specified call rate is exceeded for the key value. Policy expressions aren't allowed. |  No | N/A  |
 | remaining-calls-header-name    | The name of a response header whose value after each policy execution is the number of remaining calls allowed for the key value in the time interval specified in the `renewal-period`. Policy expressions aren't allowed. |  No | N/A  |
@@ -63,6 +63,7 @@ To understand the difference between rate limits and quotas, [see Rate limits an
 
 * [!INCLUDE [api-management-rate-limit-key-scope](../../includes/api-management-rate-limit-key-scope.md)]
 * [!INCLUDE [api-management-self-hosted-gateway-rate-limit](../../includes/api-management-self-hosted-gateway-rate-limit.md)] [Learn more](how-to-self-hosted-gateway-on-kubernetes-in-production.md#request-throttling)
+* When `increment-condition` or `increment-count` are defined using expressions, evaluation and increment of rate limit counter are postponed to end of outbound pipeline to allow for policy expressions based on the reponse. Limit exceeded condition is not evaluated at the same time in this case and will be evaluated on next incoming call. This leads to cases where `429 Too Many Requests` status code is returned 1 call later than usual.
 
 
 ## Example