-
Notifications
You must be signed in to change notification settings - Fork 14.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Handle Task instance history from task SDK #44952
Comments
…lowSensorTimeout` (#44954) related: #44414 We already have support for handling terminal states from the task execution side as well as the task SDK client side. (almost) and failed state is part of the terminal state. This PR extends the task runner's run function to handle cases when we have to fail a task: `AirflowFailException, AirflowSensorTimeout`. It is functionally very similar to #44786 As part of failing a task, multiple other things also needs to be done like: - Callbacks: which will eventually be converted to teardown tasks - Retries: Handled in #44351 - unmapping TIs: #44351 - Handling task history: will be handled by #44952 - Handling downstream tasks and non teardown tasks: will be handled by #44951 ### Testing performed #### End to End with Postman 1. Run airflow with breeze and run any DAG  2. Login to metadata DB and get the "id" for your task instance from TI table  3. Send a request to `fail` your task  Or using curl: ``` curl --location --request PATCH 'http://localhost:29091/execution/task-instances/0193cec2-f46b-7348-9c27-9869d835dc7b/state' \ --header 'Content-Type: application/json' \ --data '{ "state": "failed", "end_date": "2024-10-31T12:00:00Z" }' ``` 4. Refresh back the Airflow UI to see that the task is in failed state. 
…lowSensorTimeout` (apache#44954) related: apache#44414 We already have support for handling terminal states from the task execution side as well as the task SDK client side. (almost) and failed state is part of the terminal state. This PR extends the task runner's run function to handle cases when we have to fail a task: `AirflowFailException, AirflowSensorTimeout`. It is functionally very similar to apache#44786 As part of failing a task, multiple other things also needs to be done like: - Callbacks: which will eventually be converted to teardown tasks - Retries: Handled in apache#44351 - unmapping TIs: apache#44351 - Handling task history: will be handled by apache#44952 - Handling downstream tasks and non teardown tasks: will be handled by apache#44951 ### Testing performed #### End to End with Postman 1. Run airflow with breeze and run any DAG  2. Login to metadata DB and get the "id" for your task instance from TI table  3. Send a request to `fail` your task  Or using curl: ``` curl --location --request PATCH 'http://localhost:29091/execution/task-instances/0193cec2-f46b-7348-9c27-9869d835dc7b/state' \ --header 'Content-Type: application/json' \ --data '{ "state": "failed", "end_date": "2024-10-31T12:00:00Z" }' ``` 4. Refresh back the Airflow UI to see that the task is in failed state. 
See also #43437 My gut now is that we want to have have a TaskHistory row be created for each TI uuid, and at the same time as part of this PR that when a new TI try is being created (i.e. when we previoulsy changed try_number) we instead delete and create a new TI row. This likely means that anything that is FKing to TI table today should instead FK to the TIHistory! Ah, which I already created an issue for in #44975 |
Also related #44147 |
…lowSensorTimeout` (apache#44954) related: apache#44414 We already have support for handling terminal states from the task execution side as well as the task SDK client side. (almost) and failed state is part of the terminal state. This PR extends the task runner's run function to handle cases when we have to fail a task: `AirflowFailException, AirflowSensorTimeout`. It is functionally very similar to apache#44786 As part of failing a task, multiple other things also needs to be done like: - Callbacks: which will eventually be converted to teardown tasks - Retries: Handled in apache#44351 - unmapping TIs: apache#44351 - Handling task history: will be handled by apache#44952 - Handling downstream tasks and non teardown tasks: will be handled by apache#44951 ### Testing performed #### End to End with Postman 1. Run airflow with breeze and run any DAG  2. Login to metadata DB and get the "id" for your task instance from TI table  3. Send a request to `fail` your task  Or using curl: ``` curl --location --request PATCH 'http://localhost:29091/execution/task-instances/0193cec2-f46b-7348-9c27-9869d835dc7b/state' \ --header 'Content-Type: application/json' \ --data '{ "state": "failed", "end_date": "2024-10-31T12:00:00Z" }' ``` 4. Refresh back the Airflow UI to see that the task is in failed state. 
This was done in #47223. |
Body
Usage:
airflow/airflow/models/taskinstance.py
Lines 3089 to 3095 in aaf29ee
The text was updated successfully, but these errors were encountered: