ferruzzi commented on code in PR #61702:
URL: https://github.com/apache/airflow/pull/61702#discussion_r2789600592
##########
airflow-core/src/airflow/models/serialized_dag.py:
##########
@@ -418,6 +418,68 @@ def _generate_deadline_uuids(cls, dag_data: dict[str,
Any]) -> dict[str, dict]:
return uuid_mapping
+ @classmethod
+ def _try_reuse_deadline_uuids(
+ cls,
+ existing_deadline_uuids: list[str],
+ new_deadline_data: list[dict],
+ session: Session,
+ ) -> dict[str, dict] | None:
+ """
+ Try to reuse existing deadline UUIDs if the deadline definitions
haven't changed.
+
+ Returns None if Deadline hashes are not all identical, indicating they
need to be updated.
+
+ :param existing_deadline_uuids: List of UUID strings from existing
serialized dag
+ :param new_deadline_data: List of new deadline alert data dicts from
the DAG
+ :param session: Database session
+ :return: UUID mapping dict if all match, None if any mismatch detected
+ """
+ if len(existing_deadline_uuids) != len(new_deadline_data):
+ return None
+
+ existing_alerts = session.scalars(
+
select(DeadlineAlertModel).where(DeadlineAlertModel.id.in_(existing_deadline_uuids))
+ ).all()
+
+ if len(existing_alerts) != len(existing_deadline_uuids):
+ return None
+
+ new_alerts_temp = []
+ for deadline_alert in new_deadline_data:
+ deadline_data = deadline_alert.get(Encoding.VAR, deadline_alert)
+ # Create a temporary alert for comparison
+ temp_alert = DeadlineAlertModel(
+ id="temp", # id is required for the object but isn't included
in the __eq__
Review Comment:
Yes, that can happen. Two different Dags can reuse the same DeadlineAlert
object, for example:
```
my_deadline = DeadlineAlert(stuff)
with DAG(id="dag1", deadline=my_deadline,...) as dag1:
....
with DAG(id="dag2", deadline=my_deadline,...) as dag2:
....
```
would result in two DeadlineAlertModel entries identical other than their
unique `id` and `serialized_dag_id` fields. I think the custom `__eq__` method
is the right call here. The alternative to just compare those three fields
between the two objects would just be duplicating that function, unless I'm
missing something that you are seeing?
Or perhaps I misunderstood and the point was that the custom `__eq__` was
what is causing confusion because someone might assume it's using object
equivalence instead of just checking those three fields? Maybe I need a
comment in the code to call out that it's a custom `__eq__` and not the default?
--
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]
