Задача воздушного потока с нулевым статусом

Другой случай, когда я столкнулся со вторым условием («Другие задачи не имеют статуса« null »»), - это когда экземпляр задачи был изменен, и, в частности, изменился тип оператора.

Я надеюсь, что вы уже получили ответ / смогли двигаться дальше. Я несколько раз зацикливался на этой проблеме за последний месяц, поэтому решил, что задокументирую то, что я в конечном итоге сделал, чтобы решить эту проблему.

Пример:

• Экземпляр задачи изначально является экземпляром оператора SubDag.
• Требования приводят к изменению типа оператора с оператора SubDag на оператор Python
• После изменения для оператора Python устанавливается состояние NULL.

Насколько я могу собрать воедино, происходит следующее:

• Airflow изучает оператора, связанного с каждой задачей
• Each task instance is logged into the database table task_instance
  • This table has an attribute called operator
• Когда планировщик повторно анализирует код, он ищет task_instance с правильным типом оператора; не видя его, он обновляет связанную запись (и) базы данных как state = 'удалено'
• Когда DAG впоследствии планирует, воздушный поток

Вы можете увидеть задачи, на которые повлиял этот процесс, с помощью запроса:

SELECT *
FROM task_instance
WHERE state = 'removed'

Похоже, что для воздушного потока 1.10 уже велась работа:

• https://github.com/apache/airflow/pull/3137/commit/db29af4ffb3d120ad55cd089a44b99feb7b8bf38

При этом я не уверен на 100%, основываясь на коммитах, которые я могу найти, что это решит эту проблему. Похоже, что общая философия все еще " при изменении группы DAG необходимо увеличить / изменить имя DAG ".

Мне не нравится это решение, потому что оно затрудняет повторение того, что по сути является одним конвейером. Альтернативой, которую я использовал, было следовать (частично) рекомендациям астронома и "взорвать из "истории DAG. Для этого вам необходимо:

• Остановить планировщик
• Delete the history from the dag
  • This should result in the DAG completely disappearing from the web UI
  • Если он не исчезает полностью, где-то еще работает планировщик
• Restart the scheduler
  • Note: if you're running the DAG on a schedule, be prepared for it to backfill / catchup / run its latest schedule, because you've removed the history
  • Если вы не хотите, чтобы это происходило, попробуйте Astronomer "Fast Forward" могут быть применены предложения DAG

Это может произойти, когда статус задачи был изменен вручную (вероятно, с помощью параметра «Отметить успешное выполнение») или принудительно переведен в состояние (как в upstream_failed), и задача никогда не получает значение hostname в записи и не имеет журналов или PID