FaultRule in SpikeArrest not working?

Question

I'm trying to return a custom error message when a proxy goes above its rate in a SpikeArrest policy, but SpikeArrest doesn't seem to trigger the policy assigned to handle the fault:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<SpikeArrest async="false" continueOnError="false" enabled="true"     name="SpikeArrest.BurstProtection">
    <DisplayName>SpikeArrest.BurstProtection</DisplayName>
    <FaultRules>
        <FaultRule>
            <Policy>
                <Name>RaiseFault.BurstProtection</Name>
            </Policy>
        </FaultRule>
    </FaultRules>
    <Properties/>
    <Identifier ref="request.header.sender-id"/>
    <MessageWeight ref="1"/>
    <Rate>1pm</Rate>
</SpikeArrest>

I've used the construct elsewhere before (mostly in VerifyAPIKey) and it's always worked fine, but not in this one.

Am I missing something?

We're running Apigee Edge (installation package was 14.01.0.0)

Answer 1

<FaultRules> functionality was deprecated within Policies some time ago.

If you want to raise a custom fault for SpikeArrest, first, ensure continueOnError="true" attribute is set in your SpikeArrest Policy. That allows you to ignore the system's generic response output. Second, you can check for the following condition in a subsequent policy, leveraging ratelimit.<spike_arrest_policy_name>.exceed.count variable:

...
            <!-- Spike Arrest policy -->
            <Step>
                <Name>SpikeArrest.BurstProtection</Name>
            </Step>
            <!-- RaiseFault for Spike Arrest violation -->
            <Step>
                <Condition>(ratelimit.SpikeArrest.BurstProtection.exceed.count > 0)</Condition>
                <Name>RaiseCustomFault</Name>
            </Step>
...

Once the condition is met, you raise your own custom fault msg.

It's also worth noting that SpikeArrest doesn't really have a count, per say. See here on another SO question on SpikeArrest.

IMPORTANT EDIT ratelimit.<spike_arrest_policy_name>.exceed.count>0 check does not work at this time. A good alternative, as suggested by Michael, is to leave continueOnError="true" (the default). Let the Spike Arrest fault, and then at the top of Proxy file, leverage the FaultRules section. You can check for the proper FaultRule condition as follows:

    <FaultRules>
      <FaultRule name="FaultHandling">
        <Step>
            <Condition>(fault.name = "SpikeArrestViolation")</Condition>
            <Name>RaiseSpikeCustomFault</Name>
        </Step>
      </FaultRule>
    </FaultRules>

The fault.name values are listed on the public docs site under each topic, so SpikeArrest's are here. See under "Policy-specific error codes."

Answer 2

I've not used the <FaultRules> configuration inside of policies before but I do know that the SpikeArrest policy itself will raise a fault in the message flow if the rate is violated. This sends the message to the fault flow, <FaultRules>, where you can then define a policy like RaiseFault.BurstProtection to set a custom fault response. See more info here: http://apigee.com/docs/api-services/content/fault-handling

Most policies raise a fault when their execution determines that a fault should be raised (rate limits, xml/json injection policies, oauth v2 policies, etc).

I'm not sure the type of policy you're using for RaiseFault.BurstProtection, but when you use the approach of Apigee's <FaultRules> defined in the ProxyEndpoint or TargetEndpoint, you can have an AssignMessage policy to overwrite the response message, setting the custom fault response.

I like designing my proxies using the fault rules flows in Apigee to build more of a framework for fault handling vs. a per-policy configuration for fault rules.