You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by "Bowrna (via GitHub)" <gi...@apache.org> on 2024/05/03 14:14:51 UTC
[PR] retry for failure in the queue [airflow]
Bowrna opened a new pull request, #39398:
URL: https://github.com/apache/airflow/pull/39398
related: #38304
I think to have a retry option specifically for the failure happening in queue, we need to have a separate state where we need to indicate that failure is happening due to longer queue timeout and then segregate the retry for it there. Please let me know if I am going in right direction or do you think I have to think this in different approach?
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
-->
<!--
Thank you for contributing! Please make sure that your code changes
are covered with tests. And in case of new features or big changes
remember to adjust the documentation.
Feel free to ping committers for the review!
In case of an existing issue, reference it using one of the following:
closes: #ISSUE
related: #ISSUE
How to write a good git commit message:
http://chris.beams.io/posts/git-commit/
-->
<!-- Please keep an empty line above the dashes. -->
---
**^ Add meaningful description above**
Read the **[Pull Request Guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#pull-request-guidelines)** for more information.
In case of fundamental code changes, an Airflow Improvement Proposal ([AIP](https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvement+Proposals)) is needed.
In case of a new dependency, check compliance with the [ASF 3rd Party License Policy](https://www.apache.org/legal/resolved.html#category-x).
In case of backwards incompatible changes please leave a note in a newsfragment file, named `{pr_number}.significant.rst` or `{issue_number}.significant.rst`, in [newsfragments](https://github.com/apache/airflow/tree/main/newsfragments).
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] retry for failure in the queue [airflow]
Posted by "Bowrna (via GitHub)" <gi...@apache.org>.
Bowrna commented on PR #39398:
URL: https://github.com/apache/airflow/pull/39398#issuecomment-2268244502
> > I have been working on this PR after taking a long break due to personal commitments. I have been struck in this PR. From whatever I have learnt so far, I can see that.
> >
> > 1. there is a configurable param, task_queued_timeout, that allows to configure the time above which the task can not stuck in queue. I see that this timeout is used in `schedule_job_runner.py` and it is invoked using a timer(event_scheduler) that executes the function `_fail_tasks_stuck_in_queued` periodically.
> >
> > In this function, we pick out the TI from DB that is stuck in the queue and we collect the executor and task instances and ask the executor to cleanup the struck tasks. So the work of cleaning up goes to the executor part and how it wants to handle the cleanup process. So far this cleanup is implemented only in (Celery, CeleryKubernetes, Kubernetes, LocalKubernetes) Executor.
> > In case of Celery Executor, it is marked as Failed and task is popped out from active task dict. In case of Kubernetes Executor, it only delete pods that is associated with task instance. In case of CeleryKubernetes, TI is checked if the queue is celery or k8s one and based on it one(or both) of the above two ways of cleanup is invoked. In case of LocalKubernetes, TI is filtered out for k8s and only cleanup associated with k8s executor is invoked, as the local executor doesn't have any cleanup method implementation done.
> > I have a question wrt k8s executor, if its stuck in queue for long time and the implementation at cleanup only deletes the pod. I don't see any place where the task is marked as failed ( or any other state). Can anyone help me figure out how this one works?
> > cc: @potiuk
> > https://github.com/apache/airflow/blob/3805050f34dcb575aaad690c6ad1e37f75f3b2cf/airflow/jobs/scheduler_job_runner.py#L1626-L1660
>
> @collinmcnulty this is the reason for enquiring about the type of executor.
@potiuk A gentle reminder on this as I am struck here. Thanks!
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] retry for failure in the queue [airflow]
Posted by "Bowrna (via GitHub)" <gi...@apache.org>.
Bowrna commented on PR #39398:
URL: https://github.com/apache/airflow/pull/39398#issuecomment-2227829264
I have been working on this PR after taking a long break due to personal commitments. I have been struck in this PR. From whatever I have learnt so far, I can see that.
1. there is a configurable param, task_queued_timeout, that allows to configure the time above which the task can not stuck in queue. I see that this timeout is used in `schedule_job_runner.py` and it is invoked using a timer(event_scheduler) that executes the function `_fail_tasks_stuck_in_queued` periodically.
In this function, we pick out the TI from DB that is stuck in the queue and we collect the executor and task instances and ask the executor to cleanup the struck tasks. So the work of cleaning up goes to the executor part and how it wants to handle the cleanup process. So far this cleanup is implemented only in (Celery, CeleryKubernetes, Kubernetes, LocalKubernetes) Executor.
In case of Celery Executor, it is marked as Failed and task is popped out from active task dict.
In case of Kubernetes Executor, it only delete pods that is associated with task instance.
In case of CeleryKubernetes, TI is checked if the queue is celery or k8s one and based on it one(or both) of the above two ways of cleanup is invoked.
In case of LocalKubernetes, TI is filtered out for k8s and only cleanup associated with k8s executor is invoked, as the local executor doesn't have any cleanup method implementation done.
I have a question wrt k8s executor, if its stuck in queue for long time and the implementation at cleanup only deletes the pod. I don't see any place where the task is marked as failed ( or any other state). Can anyone help me figure out how this one works?
cc: @potiuk
https://github.com/apache/airflow/blob/3805050f34dcb575aaad690c6ad1e37f75f3b2cf/airflow/jobs/scheduler_job_runner.py#L1626-L1660
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] retry for failure in the queue [airflow]
Posted by "Bowrna (via GitHub)" <gi...@apache.org>.
Bowrna commented on code in PR #39398:
URL: https://github.com/apache/airflow/pull/39398#discussion_r1596877477
##########
airflow/providers/celery/executors/celery_executor.py:
##########
@@ -469,7 +469,7 @@ def cleanup_stuck_queued_tasks(self, tis: list[TaskInstance]) -> list[str]:
for ti in tis:
readable_tis.append(repr(ti))
task_instance_key = ti.key
- self.fail(task_instance_key, None)
+ self.failed_in_queue(task_instance_key, None)
Review Comment:
ah i see. let me do that @Taragolis
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] retry for failure in the queue [airflow]
Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] commented on PR #39398:
URL: https://github.com/apache/airflow/pull/39398#issuecomment-2463470132
This pull request has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] retry for failure in the queue [airflow]
Posted by "collinmcnulty (via GitHub)" <gi...@apache.org>.
collinmcnulty commented on PR #39398:
URL: https://github.com/apache/airflow/pull/39398#issuecomment-2231761533
@RNHTTR Any insights here?
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] retry for failure in the queue [airflow]
Posted by "Bowrna (via GitHub)" <gi...@apache.org>.
Bowrna commented on PR #39398:
URL: https://github.com/apache/airflow/pull/39398#issuecomment-2228569427
> I have been working on this PR after taking a long break due to personal commitments. I have been struck in this PR. From whatever I have learnt so far, I can see that.
>
> 1. there is a configurable param, task_queued_timeout, that allows to configure the time above which the task can not stuck in queue. I see that this timeout is used in `schedule_job_runner.py` and it is invoked using a timer(event_scheduler) that executes the function `_fail_tasks_stuck_in_queued` periodically.
>
> In this function, we pick out the TI from DB that is stuck in the queue and we collect the executor and task instances and ask the executor to cleanup the struck tasks. So the work of cleaning up goes to the executor part and how it wants to handle the cleanup process. So far this cleanup is implemented only in (Celery, CeleryKubernetes, Kubernetes, LocalKubernetes) Executor.
>
> In case of Celery Executor, it is marked as Failed and task is popped out from active task dict. In case of Kubernetes Executor, it only delete pods that is associated with task instance. In case of CeleryKubernetes, TI is checked if the queue is celery or k8s one and based on it one(or both) of the above two ways of cleanup is invoked. In case of LocalKubernetes, TI is filtered out for k8s and only cleanup associated with k8s executor is invoked, as the local executor doesn't have any cleanup method implementation done.
>
> I have a question wrt k8s executor, if its stuck in queue for long time and the implementation at cleanup only deletes the pod. I don't see any place where the task is marked as failed ( or any other state). Can anyone help me figure out how this one works?
>
> cc: @potiuk
>
> https://github.com/apache/airflow/blob/3805050f34dcb575aaad690c6ad1e37f75f3b2cf/airflow/jobs/scheduler_job_runner.py#L1626-L1660
@collinmcnulty this is the reason for enquiring about the type of executor.
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] retry for failure in the queue [airflow]
Posted by "Taragolis (via GitHub)" <gi...@apache.org>.
Taragolis commented on code in PR #39398:
URL: https://github.com/apache/airflow/pull/39398#discussion_r1590159486
##########
airflow/providers/celery/executors/celery_executor.py:
##########
@@ -469,7 +469,7 @@ def cleanup_stuck_queued_tasks(self, tis: list[TaskInstance]) -> list[str]:
for ti in tis:
readable_tis.append(repr(ti))
task_instance_key = ti.key
- self.fail(task_instance_key, None)
+ self.failed_in_queue(task_instance_key, None)
Review Comment:
This one is backward incompatible change with Airflow 2.7, 2.8 and 2.9.
Maybe it is also a good idea to made separate PR in Core and and after in Provider(s)
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] retry for failure in the queue [airflow]
Posted by "Bowrna (via GitHub)" <gi...@apache.org>.
Bowrna commented on code in PR #39398:
URL: https://github.com/apache/airflow/pull/39398#discussion_r1623177973
##########
airflow/providers/celery/executors/celery_executor.py:
##########
@@ -469,7 +469,7 @@ def cleanup_stuck_queued_tasks(self, tis: list[TaskInstance]) -> list[str]:
for ti in tis:
readable_tis.append(repr(ti))
task_instance_key = ti.key
- self.fail(task_instance_key, None)
+ self.failed_in_queue(task_instance_key, None)
Review Comment:
can you explain me the logic behind splitting it into separate PR @Taragolis ?
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] retry for failure in the queue [airflow]
Posted by "potiuk (via GitHub)" <gi...@apache.org>.
potiuk commented on PR #39398:
URL: https://github.com/apache/airflow/pull/39398#issuecomment-2268583249
I am not particularly experienced in kubernetes APIS there :( - would have to take a deeper look - but maybe others (@RNHTTR ? @Taragolis can help)?
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] retry for failure in the queue [airflow]
Posted by "github-actions[bot] (via GitHub)" <gi...@apache.org>.
github-actions[bot] closed pull request #39398: retry for failure in the queue
URL: https://github.com/apache/airflow/pull/39398
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] retry for failure in the queue [airflow]
Posted by "RNHTTR (via GitHub)" <gi...@apache.org>.
RNHTTR commented on code in PR #39398:
URL: https://github.com/apache/airflow/pull/39398#discussion_r1684729030
##########
airflow/settings.py:
##########
@@ -98,6 +98,7 @@
STATE_COLORS = {
"deferred": "mediumpurple",
"failed": "red",
+ "failed_in_queue": "reddishorange",
Review Comment:
This is `"coral"` in `airflow/utils/state.py` -- should these match?
--
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: commits-unsubscribe@airflow.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org