Apache Airflow: How to restart a failed task on Airflow
Задача A упала. Задача B уже отработала успешно. Задача C висит в ожидании, потому что зависит от A. И теперь весь ваш даг выглядит как стройка, где прораб ушел
Задача A упала. Задача B уже отработала успешно. Задача C висит в ожидании, потому что зависит от A. И теперь весь ваш даг выглядит как стройка, где прораб ушел в запой.
Вы смотрите на этот красный квадратик задачи A в интерфейсе Airflow и думаете: “Неужели мне теперь перезапускать весь даг с начала?” Это же означало бы запустить и уже успешную задачу B, потратив лишние ресурсы и время.
К счастью, в Airflow есть более элегантный путь. Вам не нужен перезапуск всего даг-рана. Вам нужно заставить систему пересчитать только упавшую задачу и ее зависимых потомков.
Решение лежит в интерфейсе, в действии под названием “Clear” (Очистить). Вот как это работает.
Перейдите в ваш даг и откройте конкретный прогон, который завершился с ошибкой. Выберите вкладку Graph View — это наглядное представление вашего пайплайна. Найдите на графе ту самую задачу A, которая подвела команду.
Кликните на этот прямоугольник. Справа появится меню с деталями задачи. Среди кнопок действий вы найдете “Clear”. Нажмите на нее.
После этого статус задачи A для данного даг-рана будет сброшен. Для планировщика Airflow это будет означать, что задача никогда не выполнялась в контексте этого прогона. Он увидит, что ее зависимости (если они были) удовлетворены, и поставит ее в очередь на выполнение.
Как только задача A завершится успешно, планировщик автоматически запустит задачу C, потому что ее триггерное правило — “все родители успешны” — наконец-то сработает. Задача B при этом останется в состоянии success, ее состояние затронуто не будет.
Это работает, потому что операция “Clear” применяется точечно к конкретной задаче в конкретном даг-ране. Она не перезаписывает историю выполнения, а добавляет новую попытку. В дереве задач вы увидите новый try_number для задачи A.
Важный нюанс: будьте осторожны, очищая задачи, которые уже находятся в состоянии success или running. Вы можете инициировать повторное выполнение, которое не требовалось. Всегда проверяйте, что вы очищаете именно ту задачу и в том даг-ране, который нужен.
Таким образом, вы не просто перезапускаете упавшую задачу. Вы вручную корректируете состояние рабочего потока, позволяя ему продолжить работу с точки сбоя. Это как починить одно звено в цепи, а не переплавлять ее целиком. Просто, эффективно и именно то, что нужно в 99% подобных ситуаций.