vladimirbinshtok commented on issue #52943:
URL: https://github.com/apache/airflow/issues/52943#issuecomment-3044932880
@fweilun The way to reproduce the issue is to create an ECS Task Definition
with a wrong command that the container cannot execute (run-script in my
example).
In that case, the `describe_tasks` will return the following JSON.
```
{
"tasks": [
{
...
"stopCode": "TaskFailedToStart",
"stoppedReason": "CannotStartContainerError:
ResourceInitializationError: failed to create new container runtime task:
failed to create shim task: OCI runtime create failed: runc create failed:
unable to start container process: error during container init: exec:
run-script: executable file not found in $PATH: unknown",
...
}
],
"failures": [],
"ResponseMetadata": {
...
}
}
```
There is, for some reason, a special handling of `TaskFailedToStart`
`ResourceInitializationError`, which leads to a retry of `_check_success_task`
function (that without `arn` returns None):
```Python
def should_retry_eni(exception: Exception):
"""Check if exception is related to ENI (Elastic Network Interfaces)."""
if isinstance(exception, EcsTaskFailToStart):
return any(
eni_reason in exception.message
for eni_reason in ["network interface provisioning",
"ResourceInitializationError"]
)
return False
```
I also reproduced the issue when the task is `TaskFailedToStart`, but the
stoppedReason is `'CannotPullContainerError: pull image manifest has been
retried 1 time(s)`, the Airflow marks the DAG as Failed, as expected.
I don't understand the reason for this custom handling of
`TaskFailedToStart` errors that lead to retries in specific cases.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
