+ "smithy.api#documentation": "<p>Starts a new task using the specified task definition.</p>\n <note>\n <p>On March 21, 2024, a change was made to resolve the task definition revision before authorization. When a task definition revision is not specified, authorization will occur using the latest revision of a task definition.</p>\n </note>\n <note>\n <p>Amazon Elastic Inference (EI) is no longer available to customers.</p>\n </note>\n <p>You can allow Amazon ECS to place tasks for you, or you can customize how Amazon ECS places\n\t\t\ttasks using placement constraints and placement strategies. For more information, see\n\t\t\t\t<a href=\"https://docs.aws.amazon.com/AmazonECS/latest/developerguide/scheduling_tasks.html\">Scheduling Tasks</a> in the <i>Amazon Elastic Container Service Developer Guide</i>.</p>\n <p>Alternatively, you can use <code>StartTask</code> to use your own scheduler or place\n\t\t\ttasks manually on specific container instances.</p>\n <p>You can attach Amazon EBS volumes to Amazon ECS tasks by configuring the volume when creating or\n\t\t\tupdating a service. For more infomation, see <a href=\"https://docs.aws.amazon.com/AmazonECS/latest/developerguide/ebs-volumes.html#ebs-volume-types\">Amazon EBS volumes</a> in the <i>Amazon Elastic Container Service Developer Guide</i>.</p>\n <p>The Amazon ECS API follows an eventual consistency model. This is because of the\n\t\t\tdistributed nature of the system supporting the API. This means that the result of an\n\t\t\tAPI command you run that affects your Amazon ECS resources might not be immediately visible\n\t\t\tto all subsequent commands you run. Keep this in mind when you carry out an API command\n\t\t\tthat immediately follows a previous API command.</p>\n <p>To manage eventual consistency, you can do the following:</p>\n <ul>\n <li>\n <p>Confirm the state of the resource before you run a command to modify it. Run\n\t\t\t\t\tthe DescribeTasks command using an exponential backoff algorithm to ensure that\n\t\t\t\t\tyou allow enough time for the previous command to propagate through the system.\n\t\t\t\t\tTo do this, run the DescribeTasks command repeatedly, starting with a couple of\n\t\t\t\t\tseconds of wait time and increasing gradually up to five minutes of wait\n\t\t\t\t\ttime.</p>\n </li>\n <li>\n <p>Add wait time between subsequent commands, even if the DescribeTasks command\n\t\t\t\t\treturns an accurate response. Apply an exponential backoff algorithm starting\n\t\t\t\t\twith a couple of seconds of wait time, and increase gradually up to about five\n\t\t\t\t\tminutes of wait time.</p>\n </li>\n </ul>\n <p>If you get a <code>ConflictException</code> error, the <code>RunTask</code> request could\n\t\t\tnot be processed due to conflicts. The provided <code>clientToken</code> is already in\n\t\t\tuse with a different <code>RunTask</code> request. The <code>resourceIds</code> are the\n\t\t\texisting task ARNs which are already associated with the <code>clientToken</code>. </p>\n <p>To fix this issue:</p>\n <ul>\n <li>\n <p>Run <code>RunTask</code> with a unique <code>clientToken</code>.</p>\n </li>\n <li>\n <p>Run <code>RunTask</code> with the <code>clientToken</code> and the original\n\t\t\t\t\tset of parameters</p>\n </li>\n </ul>",
0 commit comments