dstandish commented on code in PR #39336:
URL: https://github.com/apache/airflow/pull/39336#discussion_r1607103303
##########
airflow/providers/dbt/cloud/CHANGELOG.rst:
##########
@@ -28,6 +28,11 @@
Changelog
---------
+main
+.....
+
+In Airflow 2.10.0, we fix the way try_number works, so that it no longer
returns different values depending on task instance state. Importantly, after
the task is done, it no longer shows current_try + 1. Thus in 3.8.1 we patch
this provider to fix try_number references so they no longer adjust for the
old, bad behavior.
+
Review Comment:
Hi @eladkal
This newsfragment is in reference to the change to
`airflow/providers/dbt/cloud/utils/openlineage.py` in this PR.
The old code did this:
```
# generate same run id of current task instance
parent_run_id = OpenLineageAdapter.build_task_instance_run_id(
dag_id=task_instance.dag_id,
task_id=operator.task_id,
execution_date=task_instance.execution_date,
try_number=task_instance.try_number - 1,
)
```
Notice that previously it took the "public" try number attr and minused one.
Presumably, this is because when this bit of code is fired, the task has
completed and the try_number has been incremented (thus showing the "wrong"
try_number). So the old code was correcting for the bad behavior of try_number
in airflow.
In the present PR, we correct this behavior. The try_number is now only
incremented when a new try is scheduled, and it remains unchanged throughout
the task try lifecycle. The code in this provider which previously hacked
around the bad behavior is now no longer necessary, and if left in there, it
will give the wrong result. Hence the introduction of the compat shim
`_get_try_number` which is added to the same module.
--
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]
