ratelimit.Q-SetQuota.allowed.count showing 9223372036854775807 for quota policy

[majjik98]

Hello Apigee Team,

We have  implemented a code twoo quota policies in our API proxies as per the doc 

https://cloud.google.com/apigee/docs/api-platform/reference/policies/quota-policy#sharedcounters

Our product is apigee hybrid.

We tried in apigeee  x as well getting the same error.

we have implemented exact code provided in the doc

<ProxyEndpoint name="default">
    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Name>Enforce-Only</Name>  <!--First quota policy enforces quota count -->
            </Step>
        </Request>
        <Response>
            <Step>
                <Name>Count-Only</Name>   <!-- Second quota policy counts quota if call is successful -->
                <Condition>response.status.code = 200</Condition>
            </Step>
        </Response>
        <Response/>
    </PreFlow>
    <Flows/>
    <PostFlow name="PostFlow">
        <Request/>
        <Response/>
    </PostFlow>
    <HTTPProxyConnection>
        <BasePath>/quota-shared-name</BasePath>
    </HTTPProxyConnection>
    <RouteRule name="noroute"/>
</ProxyEndpoint>

First quota policy :

<Quota continueOnError="false" enabled="true" name="Enforce-Only" type="rollingwindow">
    <DisplayName>Enforce-Only</DisplayName>
    <Properties/>
    <Allow count="5"/>
    <Interval>2</Interval>
    <TimeUnit>minute</TimeUnit>
    <Distributed>true</Distributed>
    <Synchronous>true</Synchronous>
    <EnforceOnly>true</EnforceOnly>
    <SharedName>common-proxy</SharedName>  <!-- Notice that SharedName value is the same for both Quota policies -->
</Quota>

Second Quota policy :

<Quota continueOnError="false" enabled="true" name="Count-Only" type="rollingwindow">
    <DisplayName>Count-Only</DisplayName>
    <Properties/>
    <Allow count="5"/>
    <Interval>2</Interval>
    <TimeUnit>minute</TimeUnit>
    <Distributed>true</Distributed>
    <Synchronous>true</Synchronous>
    <CountOnly>true</CountOnly>
    <SharedName>common-proxy</SharedName>  <!-- Same name as the first policy -->
</Quota>

but we are seeing wrong count in the trace.

Could you please suggest this behaviour we are facing.

@AlexET @dchiesa1 

[dchiesa1]

I think what you are seeing is confusing. And I think it is not a problem with the function of the Quota policy. I notice that you are posting only a question about what you see in Trace (Debug); You are not saying that the Quota policy is not functioning correctly. 

The number 9223372036854775807 is the maximum value of a 64-bit integer. It seems The Debug UI is simply displaying that value. 

But Why is that value there?

With a rollingwindow quota, there is no "available count".  There is only the configured limit, which in your case is 5 every 2 minutes. The window moves forward at every execution of the Quota policy. So there's no such thing as "remaining available".  When the quota executes, it's either "allowed" or "denied".  Either the accumulated count is under the limit, or it is not. 

So the quota runtime has set "MAXINT" into the "available" variable to indicate... that this variable holds no meaning in this context. 

I think the solution is: you should ignore that value when using "rollingwindow" Quota.

[majjik98]

1. This values 9223372036854775807 only we are seeing in the trace only for the second quota policy. For the first quota policy the numbers we are observing in the trace as expected its like allow count is 5, available count is 2, used count 3 whereas for the second policy the available count and allowed count is showing 64-biit integer.  So here I want to understand why we are seeing 64 digit int numbers only for 2nd quota policy  not for 1st quota policy. Here as you could see in provide quota policy code we have used the same quota type for both quota policies.

[dchiesa1]

This values only we are seeing for second quota policy for quota policy the numbers we are seeing in the trace as expected.

I don't understand what you wrote here. It's not making sense to me.

Do you understand what I wrote? The number you are seeing is irrelevant for the Rolling Window Quota type. Did you get that?

[majjik98]

We are observing an unusual behavior with the second quota policy in the trace. While the first quota policy displays numbers as expected (e.g., allow count is 5, available count is 2, used count is 3), the second quota policy shows a 64-bit integer value like 9223372036854775807 for both the available count and allowed count.

I would like to understand why we are seeing these 64-bit integer values only for the second quota policy and not for the first one, given that the same quota type rolling window has been used for both policies.

Also we tried below code as well, same issue we have observed

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<Quota continueOnError="false" enabled="true" name="Q-Secondquota">

<DisplayName>Q-Secondquota</DisplayName>

<Identifier ref="client_id"/>

<Allow count="50" countRef="apiproduct.developer.quota.limit"/>

<Interval ref="apiproduct.developer.quota.interval">1</Interval>

<TimeUnit ref="apiproduct.developer.quota.timeunit">minute</TimeUnit>

<MessageWeight>4</MessageWeight>

<CountOnly>true</CountOnly>

<SharedName>test</SharedName>

</Quota>

1st quota policy

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<Quota continueOnError="false" enabled="true" name="QuotaFirst">

<DisplayName>QuotaFirst</DisplayName>

<Identifier ref="client_id"/>

<StartTime ref="app.startTime">2024-01-01 00:00:00</StartTime>

<Allow count="50" countRef="apiproduct.developer.quota.limit"/>

<Interval ref="apiproduct.developer.quota.interval">1</Interval>

<TimeUnit ref="apiproduct.developer.quota.timeunit">minute</TimeUnit>

<EnforceOnly>true</EnforceOnly>

<SharedName>test</SharedName>

</Quota>

[dchiesa1]

I tried this on my own Apigee X, and I did not see the behavior you reported. 

If you are seeing 9223372036854775807 in the trace output for a Quota policy, whether it is  rollingwindow or not, and would like to investigate that as a possible bug in Apigee, I suggest that you contact Apigee support and raise a bug.  You can work through it with them. Be prepared to supply a test case, with a proxy and instructions for how to invoke it to observe the behavior you're troubled by.

On the other hand, I don't know if taking that step will be worth your time. I think the behavior you have reported is irrelevant.  You're not observing a problem with the behavior of the policy.  Your question is related to what you are observing in a trace output. I have stated this in my original reply on this thread, and then when you asked again, I asked you to re-read what I wrote and  confirm that you understand what I wrote. and you did not respond to that. 

So this will be my last reply. I'm not sure if you're a bot, or just not interested in dialogue. If you are not a bot and have more questions, please re-read what I already wrote above. 

Good luck!

[majjik98]

Thanks for your response. It's a bug in Apigee, and that has been confirmed. I’ve read your comments and I understand what you said.

I'm not sure why you're unable to reproduce the steps. I provided the steps in my initial comment to help recreate the issue. It’s possible that the issue wasn't reproduced because you might have used the default quota policies configuration, instead of the synchronization, enforce, count, and shared name configuration in the quota policies.