Is there any parameter that we could log to indicate that there was a failure & also indicate the request was retried successfully by apigeex incases of http timeout/io timeout/server unhealthy response condition ? Documentation of apigeex says that it is automated & Retry is enabled bydefault.
Retry
If retry is enabled, a request will be retried whenever a response failure (I/O error or HTTP timeout) occurs or the response received matches a value set by <ServerUnhealthyResponse>. See Maximum failures above for more on setting <ServerUnhealthyResponse>.
By default <RetryEnabled> is set to true. Set to false to disable retry. For example:
<RetryEnabled>false</RetryEnabled>
Note: There must be a minimum of two target servers defined in the target endpoint configuration for retry to work.
Hi @raghunathapalle, thanks for your question, while the community reviews this, check out these resources:
We invite our Apigee experts to dive into the discussion and share their insights!
Hi raghunathapalle!
Regarding your question about finding a specific parameter to log automated retry attempts and successes: the exact flow variable for tracking these automated retries is not explicitly detailed in the provided documentation sources. However, recent Apigee platform updates have included improvements to better capture relevant target flow variables in trace and analytics specifically in the event of target timeouts.
To explore how others are handling and logging this exact target routing scenario, I highly recommend checking out the community Knowledge Hub article titled “Apigee Target Failover & Circuit Breaking - Error Retry Strategies”. This guide dives into advanced failover, retry configurations, and handling errors across multiple target servers.
To help the community investigate further if that article doesn’t fully cover your use case, could you clarify a couple of details?
-
Logging Mechanism: How are you currently trying to log this information? (For example, are you using the MessageLogging policy in the PostClientFlow, or are you hoping to view this natively in Apigee API Analytics?)
-
Debug Trace: When an I/O timeout and successful retry occurs, have you checked your Debug sessions to see if standard target flow variables (such as target.ip or target.host) populate with multiple values or reflect the final successful target server?
Let us know what you find, and we will be happy to keep troubleshooting with you!
thank you for replying on my question.
- we are use MessageLogging policy to log the metadata for the transaction in postclientflow. we use different variables that are available in apigeex to generate this metadata. for eg: env, host, uri, targetserver, targetip, loadbalancing.isfallback, loadbalancing.failedservers, log.latency.request.total,log.latency.target, log.latency.proxy etc. so we were wondering if there is any variable that we could use to indicate if there is a retry similar to fallback.
- We have huge traffic for this api proxy & the retry happens in very few scenarios but since it is payment related api proxy we wanted to avoid duplicate requests to backend or know exactly when it happened using logging.
hi @raghunathapalle
for point 1, refer to Flow variables reference | Apigee | Google Cloud Documentation - you could also pass the Globally unique MessageID string: Flow variables reference | Apigee | Google Cloud Documentation
This would allow your target and/or logging subsystem to be able to independently deduplicate entries.
For point 2, could you clarify, are the duplicate requests corresponding to a single Apigee API call proxy invocation, where the first is a failed attempt - for a reason of timeout or connection refused, resource exhausted at target infra ? Or are there two separate valid requests from the same API Proxy invocation in Apigee ?
You can find more valuable information by inspecting the API call traffic analytics, where you will also find the HTTP status code of the target backend response, if present, or the connection attempt exception for the first of the calls, if this is the case, instead.