jens-scheffler-bosch commented on code in PR #31301:
URL: https://github.com/apache/airflow/pull/31301#discussion_r1221015389
##########
airflow/example_dags/example_params_ui_tutorial.py:
##########
@@ -278,13 +276,8 @@
},
) as dag:
- @task(task_id="show_params")
- def show_params(**kwargs) -> None:
- ti: TaskInstance = kwargs["ti"]
- dag_run: DagRun = ti.dag_run
- if not dag_run.conf:
- print("Uups, no parameters supplied as DagRun.conf, was the
trigger w/o form?")
- raise AirflowSkipException("No DagRun.conf parameters supplied.")
- print(f"This DAG was triggered with the following
parameters:\n{json.dumps(dag_run.conf, indent=4)}")
+ @task
+ def show_params(params: ParamsDict = dag.params) -> None:
+ print(f"This DAG was triggered with the following
parameters:\n\n{json.dumps(params, indent=4)}\n")
Review Comment:
This example is about params.
While taking a look (again) on it I realized that it was using
`dag_run.conf` previously. From what I saw how people use `dag_run.conf` it is
actually in most cases better to consistently use `params` - and to make the
tutorial consistent I adjusted it here.
Difference is: Even if scheduled or transmitted via API not passing conf,
`params`is always there. `dag_run-conf` can be empty and you need to implement
a fallback in all cases. This is just confusing.
Besides also usage of `params` makes the code much leaner and type safe as
you can see less lines of code :-D
--
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]
