Так точно

Я как раз разбираюсь со странным косяком - даг с четырьмя тасками без зависимостей (запускаются одновременно) и три их них падают с ошибкой

[SQL: DELETE FROM rendered_task_instance_fields WHERE rendered_task_instance_fields.dag_id = %s AND rendered_task_instance_fields.task_id = %s AND (rendered_task_instance_fields.dag_id, rendered_task_instance_fields.task_id, rendered_task_instance_fields.execution_date) NOT IN (SELECT subq1.dag_id, subq1.task_id, subq1.execution_date 
FROM (SELECT rendered_task_instance_fields.dag_id AS dag_id, rendered_task_instance_fields.task_id AS task_id, rendered_task_instance_fields.execution_date AS execution_date 
FROM rendered_task_instance_fields 
WHERE rendered_task_instance_fields.dag_id = %s AND rendered_task_instance_fields.task_id = %s ORDER BY rendered_task_instance_fields.execution_date DESC 
 LIMIT %s) AS subq1)]

Вот и думаю, в этом ли дело)

Планировщик и уай - через базу. Воркеры и планировщик - через очередь (селери/редис)

Как раз вчера был такой эксперимент. Вэб и шедулер смотрели в разные места. Даг запускал вручную. Шедулер его не подхватывал. (Правда в шедулере, такого дага не было в папке)

Т.е. если одинаковое содержимое папок dags, то все будет работать?

Так точно

Не знал. Спасибо. Сейчас проверю...

Может даже разное содержание, но суть должна быть одна (набор файлов)  )

Просто тогда не гарантируется то, что ты получишь желаемый эффект ))))

Похоже, когда шедулер получает задание, он проверяет наличие файла в папке dags, если находит, посылает даг в очередь.

Спасибо🙏

Здрасти. Не подскажете почему шедулер сдох?:

{dag_processing.py:693} INFO - Sending termination message to manager.
{scheduler_job.py:1486} INFO - Deactivating DAGs that haven't been touched since 2020-07-09T16:27:57.589971+00:00
{helpers.py:325} INFO - Sending Signals.SIGTERM to GPID 195
{helpers.py:291} INFO - Process psutil.Process(pid=195, status='terminated') (195) terminated with exit code 0
{scheduler_job.py:1387} INFO - Exited execute loop
Exception ignored in: <bound method _ConnectionBase.del of <multiprocessing.connection.Connection object at 0x7f6c7314de10>>
Traceback (most recent call last):
 File "/usr/local/lib/python3.6/multiprocessing/connection.py", line 132, in del
   self._close()
 File "/usr/local/lib/python3.6/multiprocessing/connection.py", line 361, in _close
   _close(self._handle)
 File "/home/airflow/.local/lib/python3.6/site-packages/airflow/bin/cli.py", line 92, in sigint_handler
   sys.exit(0)
SystemExit: 0

и вообще его можно как-то с интерфейса запускать когда он дохнет? (развернут в контейнере далеко-далеко... )))

А до этого что ?

?

в интерфейсе так: The scheduler does not appear to be running. Last heartbeat was received 2 hours ago.

The DAGs list may not update, and new tasks will not be scheduled.

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

до этого вроде ничего криминального. запущенный без включенных дагов стоял ночь.  Это случаем не AIRFLOW__SCHEDULER__RUN_DURATION так работает?

Допускаю