retry-after

Full name

@azure-tools/typespec-azure-resource-manager/retry-after

Check if the Retry-After header appears in the response for long-running operations. For long-running operations, the Retry-After header indicates how long the client should wait before polling the operation status. This header should be included in 201 or 202 responses.

❌ Incorrect

Custom long-running operation missing Retry-After header:

@armResourceOperations
interface FooResources {
  @Azure.Core.pollingOperation(FooResources.getOperationStatus)
  @post
  update(): FooResource;

  getOperationStatus(): {
    status: Status;
  };
}

✅ Correct

Use ARM operation templates which include the Retry-After header automatically:

@armResourceOperations
interface FooResources {
  start is ArmResourceActionAsync<FooResource, FooRequestBody, FooResponse>;
}

Or include Foundations.RetryAfterHeader in your custom response:

@armResourceOperations
interface FooResources {
  @Azure.Core.pollingOperation(FooResources.getOperationStatus)
  @post
  update(): FooResource & Foundations.RetryAfterHeader;

  getOperationStatus(): {
    status: Status;
  };
}

Reviewer advice

Impacts the API and client polling behavior: long-running operations that omit the Retry-After header in their 201 or 202 responses leave clients without guidance on how long to wait before polling. Ask the author to use the standard ARM async operation templates, which add the header automatically, or to include Foundations.RetryAfterHeader in a custom response. Suppression is acceptable when the operation is not actually long-running.