kgskgs commented on code in PR #68947:
URL: https://github.com/apache/airflow/pull/68947#discussion_r3470160905
##########
airflow-core/tests/unit/models/test_serialized_dag.py:
##########
@@ -423,6 +423,27 @@ def
test_new_dag_versions_are_created_if_there_is_a_dagrun(self, dag_maker, sess
assert session.scalar(select(func.count()).select_from(DagVersion)) ==
2
assert session.scalar(select(func.count()).select_from(SDM)) == 2
+ def
test_new_dag_version_is_created_when_version_exists_but_serialized_dag_row_missing(
+ self, dag_maker, session
+ ):
+ with dag_maker("dag1") as dag:
+ PythonOperator(task_id="task1", python_callable=lambda: None)
+ assert session.scalar(select(func.count()).select_from(SDM)) == 1
+ assert session.scalar(select(func.count()).select_from(DagVersion)) ==
1
+
+ # Simulate the broken state: DagVersion present, serialized_dag row
gone.
+ session.execute(delete(SDM).where(SDM.dag_id == dag.dag_id))
+ session.flush()
+ assert session.scalar(select(func.count()).select_from(SDM)) == 0
+ assert session.scalar(select(func.count()).select_from(DagVersion)) ==
1
Review Comment:
Yes I've ran into this myself, but I am not sure what caused it, I am also
running a custom application built on top of airflow so most likely it was not
caused by airflow itself (I suspect it happened when upgrading from airflow 2
to 3 but there is lots of custom code, sometimes too tightly coupled to airflow
and it would be a lot of effort to determine exactly how it happened)
I'd say that there being nothing preventing you from getting into this state
+ the user being able to manually break their dags by editing the db is reason
enough to have this
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
