Me encontré en una situación en la que activé manualmente una ejecución DAG (a través de airflow trigger_dag datablocks_dag) y la ejecución Dag aparece en la interfaz, pero luego permanece en "Ejecución" para siempre sin hacer nada.

Cuando inspecciono esta ejecución de DAG en la interfaz de usuario, veo lo siguiente:

enter image description here

Tengo start_date configurado en datetime(2016, 1, 1) y schedule_interval configurado en @once. Mi entendimiento al leer los documentos es que desde start_date @once se asegura de que solo suceda una vez.

Mi archivo de registro dice:

[2017-07-11 21:32:05,359] {jobs.py:343} DagFileProcessor0 INFO - Started process (PID=21217) to work on /home/alex/Desktop/datablocks/tests/.airflow/dags/datablocks_dag.py
[2017-07-11 21:32:05,359] {jobs.py:534} DagFileProcessor0 ERROR - Cannot use more than 1 thread when using sqlite. Setting max_threads to 1
[2017-07-11 21:32:05,365] {jobs.py:1525} DagFileProcessor0 INFO - Processing file /home/alex/Desktop/datablocks/tests/.airflow/dags/datablocks_dag.py for tasks to queue
[2017-07-11 21:32:05,365] {models.py:176} DagFileProcessor0 INFO - Filling up the DagBag from /home/alex/Desktop/datablocks/tests/.airflow/dags/datablocks_dag.py
[2017-07-11 21:32:05,703] {models.py:2048} DagFileProcessor0 WARNING - schedule_interval is used for <Task(BashOperator): foo>, though it has been deprecated as a task parameter, you need to specify it as a DAG parameter instead
[2017-07-11 21:32:05,703] {models.py:2048} DagFileProcessor0 WARNING - schedule_interval is used for <Task(BashOperator): foo2>, though it has been deprecated as a task parameter, you need to specify it as a DAG parameter instead
[2017-07-11 21:32:05,704] {jobs.py:1539} DagFileProcessor0 INFO - DAG(s) dict_keys(['example_branch_dop_operator_v3', 'latest_only', 'tutorial', 'example_http_operator', 'example_python_operator', 'example_bash_operator', 'example_branch_operator', 'example_trigger_target_dag', 'example_short_circuit_operator', 'example_passing_params_via_test_command', 'test_utils', 'example_subdag_operator', 'example_subdag_operator.section-1', 'example_subdag_operator.section-2', 'example_skip_dag', 'example_xcom', 'example_trigger_controller_dag', 'latest_only_with_trigger', 'datablocks_dag']) retrieved from /home/alex/Desktop/datablocks/tests/.airflow/dags/datablocks_dag.py
[2017-07-11 21:32:07,083] {models.py:3529} DagFileProcessor0 INFO - Creating ORM DAG for datablocks_dag
[2017-07-11 21:32:07,234] {models.py:331} DagFileProcessor0 INFO - Finding 'running' jobs without a recent heartbeat
[2017-07-11 21:32:07,234] {models.py:337} DagFileProcessor0 INFO - Failing jobs without heartbeat after 2017-07-11 21:27:07.234388
[2017-07-11 21:32:07,240] {jobs.py:351} DagFileProcessor0 INFO - Processing /home/alex/Desktop/datablocks/tests/.airflow/dags/datablocks_dag.py took 1.881 seconds

¿Qué podría estar causando el problema?

¿Estoy entendiendo mal cómo funciona start_date?

¿O son las líneas schedule_interval WARNING que parecen preocupantes en el archivo de registro posiblemente la fuente del problema?

15
Aleksey Bilogur 12 jul. 2017 a las 04:53

2 respuestas

La mejor respuesta

El problema es que el dag está en pausa.

En la captura de pantalla que ha proporcionado, en la esquina superior izquierda, gire esto a On y eso debería hacerlo.

Este es un problema común cuando se comienza con el flujo de aire.

19
jhnclvr 12 jul. 2017 a las 13:59

La respuesta aceptada es correcta. Este problema se puede manejar a través de la interfaz de usuario.

Otra forma de manejar esto es mediante la configuración.

De forma predeterminada, todos los perros se detienen en la creación. Puede verificar la configuración predeterminada en airflow.cfg

# Are DAGs paused by default at creation
dags_are_paused_at_creation = True

Encender la bandera comenzará su día después del siguiente latido.

problema de git relevante

2
caped114 21 ene. 2020 a las 10:27