jerryzhou196 commented on PR #71318: URL: https://github.com/apache/airflow/pull/71318#issuecomment-5227371924
Closing this — the change is wrong. With \`start_from_trigger=True\` the operator never runs on a worker, so \`render_template_fields()\` is never called on it. The scheduler reads \`start_trigger_args\` straight off the serialized DAG (\`serialized_objects.py\`, captured at parse time right after \`__init__\`) and \`TaskInstance.defer_task()\` builds the \`Trigger\` row from \`trigger_kwargs\`. Building the kwargs in \`render_template_fields()\` would ship an empty \`trigger_kwargs\` in the serialized DAG and the trigger would be instantiated without \`job\`/\`region\`/\`project_id\`. The un-rendered Jinja in \`trigger_kwargs\` is deliberate: \`airflow-core/src/airflow/triggers/base.py\` filters the operator's \`template_fields\` down to the keys present in \`start_trigger_args.trigger_kwargs\` that also exist on the trigger, and the triggerer calls \`BaseTrigger.render_template_fields()\` before running it. Rendering for this path happens in the triggerer, not on a worker. Follow-up PR narrows the \`validate-operators-init\` hook to sanction this pattern instead. --- Drafted-by: Claude Code (Opus 5) (no human review before posting) -- 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]
