ServiceCallout status code is populating as null for timeout or connection refused errors
Hi Team,
I am working on fault handling for the service callout policy. However, the testResponse.status.code or testResponse.error.code is getting populated as null in case of connection timed out error.
In service callout policy , I have given the response variable name as "testResponse"
Shouldnt it populate as 504 ?
Response Body :
| Execution of ServiceCallout ServiceCallOut_TestPolicy failed. Reason: timeout occurred ServiceCallOut_TestPolicy |
Hi Apigee team,
could you pls comment on this, since I am also getting null rather 5xx/503/502 while connection-time-out and read-time out, during service callout?
You must be checking testResponse.status.code as part of <FaultRules> execution.
Can you try implementing <DefaultFaultRule> to see if you get required information.
Answer by Dino-at-Google
·
Feb 07 at 01:39 PM
No, it shouldn't populate as 504.
This is an old question, but I guess still relevant.
The 504 status code is a real status code that gets returned by a real target system. ServiceCallout is not a system, it's a policy. If the SC policy does not connect, there is no target system that can possibly return a 500 or 504 or anything. There's no connection. So the SC provides you a response that has those properties set as null, or empty, or undefined (As you like).
It is possible for the response populated by ServiceCallout to contain 500 or 503 or 504, (etc). Those all happen when a connection is made to *something*. The 504 in particular will happen when the SC actually connects to an intermediate gateway which affirmatively responds with 504, because THAT GATEWAY cannot connect to its upstream.
When the SC fails to connect directly to the upstream (and there is no intermediate gateway), this results in no status code. When the SC connects to an intermediate gateway which itself fails to connect to the upstream, the SC receives a 504.
If you want your API Proxy to return a 504 in the condition that it fails to connect directly, then you can use a Condition and a RaiseFault to implement that behavior. But that decision should not be taken within the ServiceCallout policy itself.
In regards to this,at least the SC should populate with some exit codes/reason error codes may be between (1 to 5). This way we would understand the issue is with connection,read-timeout,backendSSLcertExpiredIssue etc.
you can add your custom error code. As this is a policy fail, you should not get a backend error code.
