Flow variables not available in response header when the quota count gets exhausted.

[#1]

My requirement is to display total quota and remaining quota count in the response header. I have created a Java Script policy and used the following code in the java script file.

context.setVariable("response.header.X-RateLimit-Limit", context.getVariable("ratelimit.Quota-Minute.allowed.count"));
context.setVariable("response.header.X-RateLimit-Remaining", context.getVariable("ratelimit.Quota-Minute.available.count"));
context.setVariable("response.header.X-RateLimit-Reset", context.getVariable("ratelimit.Quota-Minute.expiry.time")); 

It is working fine and I am able to see the quota count with every response. But when the count gets exhausted the variables are no more visible. I want them to stay so that the user is aware that the minutely quota count is exhausted and will be replenished at ratelimit.Quota-Minute.expiry.time.

[dchiesa1]

when the count gets exhausted the variables are no more visible.

I think that is not true. In my tests the Quota policy sets the variables always - whether the inbound request fits under the Quota or not. Here's a screenshot showing the Trace UI. It shows a Quota policy that has thrown a fault - the inbound request exceeds the quota. You can see the variable values in the lower part of the shot.

I suspect the reason you think those variables have not been setis that the quota policy is throwing a fault, and you are not handling it with a fault rule. A Fault means the normal flow of policies is interrupted. Like an exception in a language like JavaScript or Java.

If you don't handle the fault, then the default error will be being returned to the client app, and that message does not include the information you want it to include.

The way to avoid this is to include a fault rule and specify the correct message in your policy.

For example:

  <FaultRules>
   <FaultRule name="unknown-fault">
      <!--
        This fault always message catches all uncaught faults.
        see http://docs.apigee.com/api-services/content/fault-handling
        If multiple fault rules have a condition that evaluates to true,
        then the last of those fault rules executes.
      -->
      <Condition>fault.name != "RaiseFault"</Condition>
      <Step>
        <Name>AM-UnknownFault</Name>
      </Step>
   </FaultRule>
    <FaultRule name="quota-exceeded">
      <Step>
        <Name>AM-QuotaExceeded</Name>
      </Step>
      <Condition>(fault.name = "QuotaViolation")</Condition>
    </FaultRule>
    <FaultRule name="invalid-key">
      <Step>
        <Name>AM-InvalidApiKey</Name>
      </Step>
      <Condition>(fault.name = "InvalidApiKeyForGivenResource" OR fault.name = "InvalidApiKey" OR fault.name = "DeveloperStatusNotActive" OR fault.name = "app_not_approved" OR fault.name = "invalid_client-app_not_approved")</Condition>
    </FaultRule>
    <FaultRule name="expired-key">
      <Step>
        <Name>AM-ExpiredApiKey</Name>
      </Step>
      <Condition>(fault.name = "consumer_key_expired")</Condition>
    </FaultRule>
    <FaultRule name="missing-api-key">
      <Step>
        <Name>AM-FailedToResolveAPIKey</Name>
      </Step>
      <Condition>(fault.name = "FailedToResolveAPIKey")</Condition>
    </FaultRule>
  </FaultRules>

Here you can see I have different FaultRules for various conditions. ONE of the FaultRule elements handles the quota exceeded error. Within AM-QuotaExceeded (an AssignMessage policy), I can assign whatever message I like, or I can assign header values in the response message. The quota context variables will be available in that policy.

See here for more information on fault handling in Apigee Edge.

And please find attached a working API proxy demonstrating this.

apiproxy-quota-feedback.zip