adding error codes in retry logic #7107
Conversation
vincent1173
added
Area: Release
Area: AzureAppService
| @@ -21,14 +21,8 @@ export class KuduServiceManagementClient { | |||
| request.headers = request.headers || {}; | |||
| request.headers["Authorization"] = "Basic " + this._accesssToken; | |||
| request.headers['Content-Type'] = 'application/json; charset=utf-8'; | |||
| var options: webClient.WebRequestOptions = { | |||
There was a problem hiding this comment.
Here we were adding a default list of error codes which we have now added in WebClient directly.
| let retriableErrorCodes = options && options.retriableErrorCodes ? options.retriableErrorCodes : ["ETIMEDOUT", "ECONNRESET"]; | ||
| let retriableStatusCodes = options && options.retriableStatusCodes ? options.retriableStatusCodes: []; | ||
| let retriableErrorCodes = options && options.retriableErrorCodes ? options.retriableErrorCodes : ["ETIMEDOUT", "ECONNRESET", "ENOTFOUND", "ESOCKETTIMEDOUT", "ECONNREFUSED", "EHOSTUNREACH", "EPIPE", "EA_AGAIN"]; | ||
| let retriableStatusCodes = options && options.retriableStatusCodes ? options.retriableStatusCodes: [408, 409, 500, 502, 503, 504]; |
There was a problem hiding this comment.
are 409, 500 retriable in all cases?
There was a problem hiding this comment.
@sachinma
409 - conflict happens, when multiple calls made to same resource, it sends conflict message and asks to retry after some time. (It is reliable to retry)
500 - we added this, because, many of the API calls that returned 500 passes in next retry. (for instance, Swap API monitor API failed with 500 in monitoring call, but it was passed in Azure side, so we considered retrying for 500. One more instance is with Update Application settings API, where the first call failed but second retry passed). 500 is not retriable in all cases, but given the number of instances, it passed in next retry, we took this path
No description provided.