EcsRunTaskOperator fails to run after upgrading to Airflow 3.0.1

[ebizboy]

Apache Airflow version

3.0.1

If "Other Airflow 2 version" selected, which one?

No response

What happened?

The EcsRunTaskOperator fails immediately upon execution after upgrading to Airflow 3.0.1. The following error log is produced:

[2025-05-18, 06:20:39] ERROR - Task failed with exception: source="task"
AttributeError: 'RuntimeTaskInstance' object has no attribute 'key'
  File "/opt/bitnami/airflow/venv/lib/python3.12/site-packages/airflow/sdk/execution_time/task_runner.py", line 838, in run
  File "/opt/bitnami/airflow/venv/lib/python3.12/site-packages/airflow/sdk/execution_time/task_runner.py", line 1130, in _execute_task
  File "/opt/bitnami/airflow/venv/lib/python3.12/site-packages/airflow/sdk/bases/operator.py", line 408, in wrapper
  File "/opt/bitnami/airflow/venv/lib/python3.12/site-packages/airflow/providers/amazon/aws/operators/ecs.py", line 520, in execute
  File "/opt/bitnami/airflow/venv/lib/python3.12/site-packages/pydantic/main.py", line 989, in __getattr__

This operator was working correctly in previous versions (e.g., Airflow 2.10.5 as mentioned in a related discussion). It seems an attribute key is expected from the RuntimeTaskInstance object but is no longer available or has been renamed in Airflow 3.0.1.

What you think should happen instead?

It should execute normally, as it did in versions prior to Airflow 3.0.0.

How to reproduce

Run a simple DAG that includes an EcsRunTaskOperator

Operating System

eks amazon linux 2023

Versions of Apache Airflow Providers

apache-airflow-providers-amazon 9.7.0

Deployment

Other 3rd-party Helm chart

Deployment details

bitnami airflow chart 24.0.1

Anything else?

No response

Are you willing to submit PR?

• Yes I am willing to submit a PR!

Code of Conduct

• I agree to follow this project's Code of Conduct

[boring-cyborg]

Thanks for opening your first issue here! Be sure to follow the issue template! If you are willing to raise PR to address this issue please do so, no need to wait for approval.

[tirkarthi]

It looks like RuntimeTaskInstance has no key attribute like TaskInstance model. Since in this case the key was used to form uuid maybe id of RuntimeTaskInstance which is already a uuid to uniquely identify it.

[eladkal]

cc @o-nikolas @vincbeck not sure if this is ECS specific (probably not) but best to take a quick look if you have the time

[o-nikolas]

@ebizboy Can you share a(n anonymized) Dag which triggers this issue?

[o-nikolas]

Looks like it would only happen under re-attach conditions. I'll look into it more, but a simplified Dag to trigger the issue would be nice to have

[o-nikolas]

It looks like RuntimeTaskInstance has no key attribute like TaskInstance model. Since in this case the key was used to form uuid maybe id of RuntimeTaskInstance which is already a uuid to uniquely identify it.

I don't think we want to use the RuntimeTaskInstance uuid, that would be unique always and then we'd never find a previous ECS task with the started_by with the same uuid. The code is trying to produce a UUID that possibly matches with a previous uuid.