How to retry when response code is `409`

Could you please let me know how to retry when an HTTP response code is 409 Conflict with @azure/core-pipeline-rest package?

As far as reading the code, the package seems to use 408, 500, 502-504, 506 or more as response codes that are need to retry. https://github.com/Azure/azure-sdk-for-js/blob/82996230773ab8295f06b17a8b6f449f9d9f2a8c/sdk/core/core-rest-pipeline/src/retryStrategies/exponentialRetryStrategy.ts#L81-L94

Or please add 409 to the retry target status code.

Background: We are trying to develop a GitHub actions aca-review-apps that operates revision status of Azure Container Apps and uses @azure/core-pipeline-rest via @azure/arm-appcontainers. If the operation by the action and the one from Azure portal are conflicted, then Azure platform returns HTTP 409 error as the action result. In this case we think it’s needed to retry the operation.

[xirzec]

Sorry for not being clearer. My advice is to forget about the pipeline and handle retrying the operation on the client yourself, such as:

await retryOperation(() => {  return client.containerApps.beginUpdateAndWait(/* params*/) });

async function retryOperation(callback: () => Promise<void>, retryCount = 0): Promise<void> {
  try {
    await callback();
  }
  catch (e) {
     if (isRestError(e) && e.statusCode === 409) {
          // set this to whatever limit you want
          if (retryCount < 5) {
              // wait some number of seconds
              await delay(5000);
              return retryOperation(callback, retryCount + 1);
          }
     }
     throw e;
  }
}

[xirzec]

@xirzec, is the js libraries retrying if a Retry-After header is present? If not, why not? The general recommendation is that a service should only include a Retry-After header if it feels like the request can be retried without any modifications.

Yes we support throttling using Retry-After with no additional effort from the consumer.

@horihiro Back to the issue at hand, is it true that your 409 will resolve itself in a relatively short timeframe? By default, we attempt to retry 3 times and give up after no more than around 10 seconds. While you can configure this to allow for greater delays, this configuration applies to all retry reasons, not just a single HTTP status code.

I think my suggestion here would be to not rely on pipeline magic for automatic retries and simply try/catch the client operation. This way you can detect the 409 and decide to execute the operation again as many times as you want with whatever pauses or delays you feel are necessary.