Auto Scaling:How to ensure idempotence

This topic introduces how to ensure idempotence.

If a request timeout or internal server error is encountered when the “Execute a Scaling Rule” interface is called to create or release an ECS instance, the client might try to resend the request. In this case, the client can prevent the server from creating more instances than expected by providing the optional ClientToken parameter. This parameter also ensures the idempotence of the request. ClientToken is a unique and case sensitive string which is generated by the client and cannot contain more than 64 ASCII characters.

If you use the same ClientToken value to call the CreateInstance interface, the server returns identical request results that contain the same ScalingActivityId. Therefore, when you encounter an error and try again, by providing the same ClientToken value, you can ensure that only one scaling activity is created and the corresponding ScalingActivityId is obtained.

If you provide a ClientToken that has already been used, but with different request parameters, the Auto Scaling service returns the IdempotentParameterMismatch error code. However, note that you must change the SignatureNonce, TimeStamp, and Signature parameters. Because the Auto Scaling service uses SignatureNonce to prevent replay attacks and TimeStamp to mark the time of each request, the second request must provide different SignatureNonce and TimeStamp parameter values. This also produces a different Signature value.

Generally, you only need to retry the client in the case of Error 503 (ServiceUnAvailable) or no response. When Error 200 is returned, a retry generates the same results as the last time, without affecting the server status. When Error 4xx or 500 is returned, a retry usually may fail unless the message clearly indicates try it later.