rom1mouret commented on PR #27111:
URL: https://github.com/apache/airflow/pull/27111#issuecomment-1312167394
Sorry, I should have quoted the entire code section:
```python3
next_info = dag.next_dagrun_info(dag.get_run_data_interval(ti.dag_run),
restricted=False) # 1st call
while next_info and next_info.logical_date < ts:
next_info = dag.next_dagrun_info(next_info.data_interval,
restricted=False) # 2nd call
<SLA miss detection here>
```
I agree that you need to call `next_dagrun_info` at least once to get the
actual scheduled execution time, as opposed to the start of the interval, which
is one day in the past for the current DAG run if the DAG runs daily.
The loop is also justified, since we want SLAs to be checked for past DAG
runs as well.
Actually, I'm running an older version of Airflow that detects SLA misses as
follows:
```python3
dttm = ti.execution_date
dttm = dag.following_schedule(dttm) # 1st call
while dttm < timezone.utcnow():
following_schedule = dag.following_schedule(dttm) # 2nd call
if following_schedule + task.sla < timezone.utcnow():
<SLA miss>
```
I added some debugging `print` calls and I confirm that the first SLA check
is counter-intuitively relative to a date in the future.
Perhaps it makes sense if we consider SLA to be relative to the execution
date + the theoretical max duration of the DAG? After all, it's fair to assume
that all tasks should finish before the next DAG run.
I haven't tested with the new version though, but the logic doesn’t seem to
have changed.
--
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]