Why is ExtractVariables policy not failing even with IgnoreUnresolvedVariables set to false?

[cladius_fernand]

Hi,

I've configured an ExtractVariables policy with IgnoreUnresolvedVariables set to false. However, even if the mentioned variables are not resolved, the policy is not throwing an error.

The policy configuration is as below:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<ExtractVariables async="false" continueOnError="false" enabled="true" name="Extract-Access-Token">
    <DisplayName>Extract Access Token</DisplayName>
  <Properties/>
    <Header name="accessToken">
    <Pattern ignoreCase="true">{accessToken}</Pattern>
  </Header>
  <QueryParam name="code">
   <Pattern ignoreCase="true">DBN{dbncode}</Pattern>
</QueryParam>
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
</ExtractVariables>

Am I missing something here? Any help would be greatly appreciated.

[#2]

Can you post a screen shot of the trace output for this policy when you expect it would fail? Some context would help with diagnosing what is going on as your policy as written should raise a fault if accessToken or dbncode are not in the header and query params respectively.

[cladius_fernand]

Hi @David Allen, pfa the screenshot of the trace.

Currently it is failing for the subsequent policy due to the missing variable but not for the ExtractVariables policy. Any pointers?

[#4]

I have raised an internal bug on this issue for engineering to review. Apologize for the inconvenience as I learn more I will update this question.

[#5 · Accepted solution]

Hmmm... based on this I would expect the policy to raise the fault. If you would like you can add me to your org temporarily and I can take a look. As you have presented it here I would expect a fault to be raised.

A couple of possibilities: you are running against an obsolete revision of the proxy, your change isn't deployed to the dev environment, you have two copies of the policy defined with the one actually being executed not having ignoreUnresolvedVariables set to false, or perhaps even something wonkier than that...

[cladius_fernand]

Thanks, @David Allen. Could you please share your email-address?

[#7]

dallen at apigee dot com

[williamking]

Just came across this when looking into the same issue. From looking at the docs, I believe that setting the "ignore" to false means that an unmatched variable is actually set to null or an empty string (the docs aren't clear on which). That way you can reference the variable in another policy without triggering an exception.

Here's the docs:

http://docs.apigee.com/api-services/reference/extract-variables-policy

If the pattern does not match, then the corresponding variable is not created. Therefore, if another policy references the variable, it can cause an error.

One option is to set <IgnoreUnresolvedVariables> to true in a policy that references the variable to configure the policy to treat any unresolvable variable as an empty string (null)