dagbag_import_timeout

Ну с 1.10.6 вроде как

min_file_process_interval

dagbag_*_timeout (их там несколько) вроде как про то, через сколько грохать процесс, даги читающий

dag_dir_list_interval

как-то так

Так, проблема решилась: запустил таксу через консоль тестом. Она и там прошла и теперь через веб-морду даг тригерится с правильной командой

хз, что было
Но, кажется, это не из-за настроек кофига: там везде таймеры в секундах-минутах, а у меня несколько часов висел измененный даг

как я сказал, там совокупность

шедулер не будет перечитывать файл, если для шедулера ничего не поменялось

вот хз, зачем так сделали

Для уменьшения нагрузки мб?

Но в целом печально и неочевидно

так, проверили, min_file_process_interval и dag_dir_list_interval должны корректно поддерживать рефреш дагов, но стоит помнить вот этот момент, который мы используем:
"Следующий неочевидный совет – при изменении schedule_interval или start_date нужно менять dag_id. Это связано с тем, что в базе метаданных Airflow уже есть запись о том, что такой-то пайплайн запускается тогда-то. При изменении расписания в таблицу DAGS добавляется еще одна строчка, что сводит с ума Scheduler, потому что он видит два пайплайна с разным расписанием. Для решения этой проблемы мы раньше указывали версию в названии пайплайнов, но сейчас мы перешли на подход, при котором вшиваем расписание прямо в dag_id. Таким образом пайплайн автоматически получает новое имя, и этим не нужно заниматься вручную."
https://habr.com/ru/company/lamoda/blog/518620/

Интересно, что я не нашёл этого в документации. Там сказано никогда не удалять таски из дагов. Мол, если удаляете, создавайте новый даг. Но предупреждений по изменению расписания нет. Может, для 2.0 это неактуально?

Спросил в слэке, говорят, что ерунда это всё, и расписание можно менять смело без особых побочных эффектов

А что за слэк?)

я конечно могу проверить это, но раньше это точно не ерунда была

Спасибо