dejii opened a new pull request, #60619: URL: https://github.com/apache/airflow/pull/60619
<!-- Thank you for contributing! Please provide above a brief description of the changes made in this pull request. Write a good git commit message following this guide: http://chris.beams.io/posts/git-commit/ Please make sure that your code changes are covered with tests. And in case of new features or big changes remember to adjust the documentation. Feel free to ping (in general) for the review if you do not see reaction for a few days (72 Hours is the minimum reaction time you can expect from volunteers) - we sometimes miss notifications. In case of an existing issue, reference it using one of the following: * closes: #ISSUE * related: #ISSUE --> This PR adds the ability for individual operators to override the DAG-level `render_template_as_native_obj` setting, enabling fine-grained control over template rendering behavior on a per-task basis. As discussed in https://github.com/apache/airflow/discussions/30266, users have encountered situations where they need mixed template rendering behavior within the same DAG, and it is one I've had to navigate multiple times myself. Currently, `render_template_as_native_obj` can only be set at the DAG level, which means all tasks in a DAG must use the same template rendering behavior. This can be limiting when you need some tasks to receive native Python types while others need string values. Usage: ```python3 with DAG("example", render_template_as_native_obj=False): # This task renders templates as strings (inherits from DAG) task1 = PythonOperator(task_id="string_task", ...) # This task renders templates as native Python types (overrides DAG) task2 = PythonOperator( task_id="native_task", render_template_as_native_obj=True, ... ) # Works with mapped operators too mapped = PythonOperator.partial( task_id="mapped_native", render_template_as_native_obj=True, ).expand(...) ``` If there are specific reasons why this approach shouldn't be taken, I'd love to hear the feedback. Otherwise, I'm hoping to move this discussion forward as it would be a nice to have! --- ##### Was generative AI tooling used to co-author this PR? <!-- If generative AI tooling has been used in the process of authoring this PR, please change below checkbox to `[X]` followed by the name of the tool, uncomment the "Generated-by". --> - [ ] Yes (please specify the tool below) <!-- Generated-by: [Tool Name] following [the guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#gen-ai-assisted-contributions) --> --- * Read the **[Pull Request Guidelines](https://github.com/apache/airflow/blob/main/contributing-docs/05_pull_requests.rst#pull-request-guidelines)** for more information. Note: commit author/co-author name and email in commits become permanently public when merged. * For fundamental code changes, an Airflow Improvement Proposal ([AIP](https://cwiki.apache.org/confluence/display/AIRFLOW/Airflow+Improvement+Proposals)) is needed. * When adding dependency, check compliance with the [ASF 3rd Party License Policy](https://www.apache.org/legal/resolved.html#category-x). * For significant user-facing changes create newsfragment: `{pr_number}.significant.rst` or `{issue_number}.significant.rst`, in [airflow-core/newsfragments](https://github.com/apache/airflow/tree/main/airflow-core/newsfragments). -- 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]
