Apache Airflow version
main (also reproduced against current released 3.x)
What happened
DateTimeSensorAsync declares target_time as a template_fields member (rendered via Jinja against the run context at task-execution time), but its __init__ calls timezone.parse(self.target_time) at Dag-parse time when start_from_trigger=True — before Jinja rendering has happened. If target_time is a template string (the normal, documented use case for this field), this raises a parser error and crashes parsing of the entire Dag
file, not just the task.
This is the same root-cause pattern fixed for TimeSensor in #69610 (parse-time handling of a value that can only correctly be resolved at/near task-execution time), but with a more severe symptom: instead of silent dag_version churn, the whole Dag fails to parse.
Reproduction
from __future__ import annotations
import pendulum
from airflow.sdk import DAG
from airflow.providers.standard.sensors.date_time import DateTimeSensorAsync
with DAG(dag_id="repro", schedule=None, start_date=pendulum.datetime(2026, 1, 1, tz="UTC")):
DateTimeSensorAsync(
task_id="t",
target_time="{{ data_interval_end.tomorrow().replace(hour=1) }}",
start_from_trigger=True,
)
Raises at Dag-parse time:
pendulum.parsing.exceptions.ParserError: Invalid date string: {{ data_interval_end.tomorrow().replace(hour=1) }}
There is currently no test coverage for DateTimeSensorAsync combining a templated target_time with start_from_trigger=True.
What you think should happen instead
Check whether a string is passed when start_from_trigger=True. static datetime should be fine
How to reproduce
See reproduction script above; raises immediately on Dag parse.
Operating System
N/A (reproduced via breeze container, standard provider)
Deployment
Other
Deployment details
Found while reviewing #69610 (TimeSensor fix for a related parse-time issue).
Anything else
Related: #69610, #69543
Are you willing to submit PR?
Code of Conduct
Apache Airflow version
main (also reproduced against current released 3.x)
What happened
DateTimeSensorAsyncdeclarestarget_timeas atemplate_fieldsmember (rendered via Jinja against the run context at task-execution time), but its__init__callstimezone.parse(self.target_time)at Dag-parse time whenstart_from_trigger=True— before Jinja rendering has happened. Iftarget_timeis a template string (the normal, documented use case for this field), this raises a parser error and crashes parsing of the entire Dagfile, not just the task.
This is the same root-cause pattern fixed for
TimeSensorin #69610 (parse-time handling of a value that can only correctly be resolved at/near task-execution time), but with a more severe symptom: instead of silentdag_versionchurn, the whole Dag fails to parse.Reproduction
Raises at Dag-parse time:
There is currently no test coverage for
DateTimeSensorAsynccombining a templatedtarget_timewithstart_from_trigger=True.What you think should happen instead
Check whether a string is passed when start_from_trigger=True. static datetime should be fine
How to reproduce
See reproduction script above; raises immediately on Dag parse.
Operating System
N/A (reproduced via
breezecontainer, standard provider)Deployment
Other
Deployment details
Found while reviewing #69610 (
TimeSensorfix for a related parse-time issue).Anything else
Related: #69610, #69543
Are you willing to submit PR?
Code of Conduct