Fault being raised while executing a raise fault policy

[#1]

I have an issue where I am raising my own custom fault coming out of a Java Callout that sets a variable, jwt_isValid, if the fault occurs. The RaiseFault policy gets triggered, however upon execution, there is a fault while trying execute the RaiseFault policy which eventually gets handled by my default handler. I'd like to know why this second fault is occurring.

Here is the code for my preflow where it gets triggered:

            <Step>
                <Name>RaiseFault401InvalidToken</Name>
                <Condition>jwt_isValid="false"</Condition>
            </Step>

Here is the policy itself:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<RaiseFault async="false" continueOnError="false" enabled="true" name="RaiseFault401InvalidToken">
    <DisplayName>RaiseFault.401InvalidToken</DisplayName>
    <Properties/>
    <FaultResponse>
        <Set>
            <Headers/>
            <Payload contentType="application/json" variablePrefix="@" variableSuffix="#">{"exceptions":[{"type": "E","code": "401","message": "Invalid Token","detail": "details"}]}</Payload>
            <StatusCode>401</StatusCode>
            <ReasonPhrase>Invalid Token</ReasonPhrase>
        </Set>
    </FaultResponse>
    <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
</RaiseFault>

And here is the trace table output for the step when it fails:

Variables Read and Assigned
raisefault.failed	true
raisefault.RaiseFault401InvalidToken
apigee.edge.execution
messageid	*****_CVAHK7MOO_RouterProxy-10-46_2
Error Headers
Content-Type	Error Content
Body	Properties
action	ABORT
stepDefinition-async	false
internal	false
stepDefinition-type	raisefault
expression	(jwt_isValid equals "false")
type	RaiseFaultExecution
enforcement	request
stepDefinition-continueOnError	false
expressionResult	true
stepDefinition-displayName	RaiseFault.401InvalidToken
stepDefinition-name	RaiseFault401InvalidToken
stepDefinition-enabled	true
result	false
error	Raising fault. Fault name : RaiseFault401InvalidToken
type	ErrorPoint
state	PROXY_REQ_FLOW
error.class	com.apigee.kernel.exceptions.spi.UncheckedException
Identifier	fault

[gargi_talukdar · Accepted solution]

Hi rj.walsh,

If you are using DefaultFaultRule to check unhandled exception, could you please let me know how you have configured it.

[#3]

Thanks Gargi, it seems this is happening because the fault is raised as a RaiseFault policy, rather than as being captured by a fault rule, it still runs through the fault rules and since it doesn't match anything the default rule is being applied.

Is it correct behavior to have the default fault rule execute when a fault is raised through the RaiseFault policy? to me it doesn't seem like it should

[gargi_talukdar]

Hi @rj.walsh,

You can capture the error raised by RaiseFault Policy by having a faultRule with no policy step inside and condition as below:

<FaultRule name="CustomFaultHandling">

<Condition>(fault.name == "RaiseFault")</Condition>

</FaultRule>

or

<FaultRule name="CustomFaultHandling">

<Condition>(raisefault.failed = "true")</Condition>

</FaultRule>

DefaultFault rule is used to check unhandled exception so ideally it should not get executed when a RaiseFault is used to raise an error.

Also under the DefaultFaultRule, you can set AlwaysEnforce as false as below:

<AlwaysEnforce>false</AlwaysEnforce>

[sunandita_dam]

@rj.walsh

I would suggest you to make below changes, rest of your code should be fine. I believe this should solve the problem.

<HTTPTargetConnection>

<Properties>

<Property name="success.codes">1xx,2xx,3xx,4xx,5xx</Property>

</Properties>

<URL>http://weather.yahooapis.com</URL>

</HTTPTargetConnection>

Let me know if this works.

[gargi_talukdar]

Hi Sunandita Dam,

The property name="success.codes" is mainly used when we want to handle error from target(backend).

Let me explain in detail. When the target sends error message with 400 or 500 series http error codes, then Apigee stops processing( of any other policy) there and sends the error response as is to the consumer.

But if we want to handle that error, that instead of sending the error response from backend as is to consumer, we want to customize the error message send to consumer then this property needs to be set at targetconnection in order to first treat the 400 and 500 series codes as success in order to continue processing for further manipulation.