API Proxy with same base path (only one deployed on env) but APIs call enter the undeployed Proxy

I have 2 API Proxies with the same basepath. But I only deploy one at a time. But during API calls, the call does not appear to the deployed revision, and enters the undeployed revision. Any info on how to check/ why this is happening?

UPDATE**: I undeployed BOTH API Proxy, and API call still enters the 2nd API Proxy WHICH IS UNDEPLOYED. Why is this happening?

8607-capture.jpg

Solved Solved
1 5 465
1 ACCEPTED SOLUTION

@Junnes Ashley Pineda,

This issue can happen if the Message Processors is still having the information about the undeployed API Proxy. You can check this by running the following commands on the Message Processors:

  1. Command to check the API Proxies deployed on the Message Processor(s)
    curl -v http://localhost:8082/v1/runtime/organizations/<orgName>/environments/<envName>/apis

    If the above command shows that the specific API Proxy is still deployed, then try to undeploy again using UI and re-run the above command. If the above command shows that the specific API Proxy is not listed, then run the below command.

  2. Command to get the classification tree on the Message Processor(s)
    curl -v http://localhost:8082/v1/runtime/classification/tree

    Redirect the output of the classification tree to a file and check if the undeployed API proxy name is still referenced. If it is still referenced, then that's the cause for the issue. Restarting the Message Processor nodes should remove these stale references.

If the issue persists, please file a ticket with Apigee Support.

View solution in original post

5 REPLIES 5

Your screenshot only show the deployment information of the proxies. Apparently both are not deployed. Can't really tell what's missing base on this screenshot.

You need to share with us :

1. The deployment information of the proxies, including which env it is deployed to. Use this management api [1]

https://api.enterprise.apigee.com/v1/organizations/{org_name}/apis/{api_name}/revisions/{revision_nu...

2. Screenshot to show the curl call/POSTMAN call to the proxy endpoint.

3. Elaborate more around base on what details that you know the call reaches which version.

[1] https://apidocs.apigee.com/management/apis/get/organizations/%7Borg_name%7D/apis/%7Bapi_name%7D/revi...

Hi @Brendan, I undeployed both API Proxy from prod env. Then I triggered the API call and it enters the v2. How did I know? because there is javascript validation in v2 which returned the error during the call. My issue is that both proxy is undeployed in both test and prod env, yet when I trigger an API call, it is entering v2 API proxy. Same issue when I deploy the v1 version, it still enters the v2 even though it is not deployed.

I have a strong feeling that a revision (maybe old) of your API is still deployed.

Without full inputs from what I requested earlier, can't confirm though.

I checked all the list of API Proxies, and only those 2 are with the same basepath. Also, If there is a revision that is still deployed, it will return error when I try to deploy a new proxy of the same basepath. This happens with the above proxies.

When I deploy payment, I can't deploy payment_v2 because it returns same basepath error.

These are the list of things that I have done:

1. Delete v2 proxy, and undeploy the v1(og payment) but still, when I trigge rthe API call, it seems to enter the v2 (even though it is already deleted)

2. Delete BOTH proxies, and still it can call the v2 endpoints.

Is there any caching within Apigee components that may cause this issue? Or is this issue related with any Apigee component?

We will try to restart the nodes, and will update here if the issue will be fixed.

@Junnes Ashley Pineda,

This issue can happen if the Message Processors is still having the information about the undeployed API Proxy. You can check this by running the following commands on the Message Processors:

  1. Command to check the API Proxies deployed on the Message Processor(s)
    curl -v http://localhost:8082/v1/runtime/organizations/<orgName>/environments/<envName>/apis

    If the above command shows that the specific API Proxy is still deployed, then try to undeploy again using UI and re-run the above command. If the above command shows that the specific API Proxy is not listed, then run the below command.

  2. Command to get the classification tree on the Message Processor(s)
    curl -v http://localhost:8082/v1/runtime/classification/tree

    Redirect the output of the classification tree to a file and check if the undeployed API proxy name is still referenced. If it is still referenced, then that's the cause for the issue. Restarting the Message Processor nodes should remove these stale references.

If the issue persists, please file a ticket with Apigee Support.