Reporting Undocumented Error Code for VerifyAPIKey Policy.

[#1]

When testing Verify API Key Policy, with the xml of

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<VerifyAPIKey async="false" continueOnError="false" enabled="true" name="Verify-API-Key-1">
    <DisplayName>Verify API Key-1</DisplayName>
    <Properties/>
    <APIKey ref="request.header.AppKey"/>
</VerifyAPIKey>

and with a request of a header which is set to null (AppKey), the Error code that was sent to me was

"steps.oauth.v2.FailedToResolveAPIKey" or in short "FailedToResolveAPIKey" error code which is not defined in the document here, i have cropped also it in a picture:

I just wanted to help the community by raising this. I meant no harm in any way. Cheers!

[adas · Accepted solution]

@Hanzel Garcia Totally agreed. We can definitely take that down as an improvement request and have some implicit null checks being performed and corresponding errors being returned. However while we make this change, we have to careful about backward compatibility because a lot of customers might have implemented custom fault handling rules in their apiproxies, where they check for the current error and the give our customized error messages to their clients. I will open a improvement request with our engineering team, nevertheless.

[adas]

@Hanzel Garcia You are right. This particular error code is not documented. What this error really means is that, the variable that its supposed to refer to for the APIKey was not resolved (or not supplied in the request). We can add this in the documentation as an extension of the existing error codes. At the same time, the existing error codes deal with the various scenarios where the apikey variable was supplied but resulted in an error either because its invalid, key is not in approved status, or invalid resource etc. Whereas the FailedToResolveAPIKey is a scenario where the key variable itself was not supplied. The analogy could be a mandatory field check error on the client side vs server side error codes for a given object/variable.

@sgilson You might want to take a look at this one, and see if doc updates are necessary.

[#4]

To also suggest, could we have a better or nay; a more formal way of handling null checking on the said scenario wherein AppKey reference is null? For instance another Error code like "APIKeyIsNotFound" or "APIKeyIsNull" or something on the line or just repeat "InvalidAPIKey" in there.

[sgilson]

Thanks for point this out. I updated the doc to add FailedToResolveAPIKey as an error code:

http://apigee.com/docs/api-services/reference/veri...

Stephen

[adas · Accepted solution]

@Hanzel Garcia Totally agreed. We can definitely take that down as an improvement request and have some implicit null checks being performed and corresponding errors being returned. However while we make this change, we have to careful about backward compatibility because a lot of customers might have implemented custom fault handling rules in their apiproxies, where they check for the current error and the give our customized error messages to their clients. I will open a improvement request with our engineering team, nevertheless.

[#7]

Thanks, for now I would use "FailedToResolveAPIKey" as my default checking. I sure hope the improvements are well taken into consideration. Thanks!

[adas · Accepted solution]

@Hanzel Garcia I already filed an enhancement request for this.

[#9]

Thanks! The effort is well appreciated!