Seraph-x commented on code in PR #75503:
URL: https://github.com/apache/airflow/pull/75503#discussion_r4421008663


##########
airflow-core/src/airflow/dag_processing/lang_sdk_processor.py:
##########
@@ -194,7 +195,10 @@ def start(  # type: ignore[override]
             for listener in listeners.values():
                 listener.setblocking(False)
             parse_request = DagFileParseRequest(

Review Comment:
   Implemented a dedicated language-SDK `DagFileParseRequest` subclass in 
`lang_sdk_processor.py`. The Python parser's base request remains unchanged, 
and the subclass retains the existing `DagFileParseRequest` wire discriminator. 
The schema registry and migration use the language-SDK subclass.
   
   ---
   Drafted-by: OpenAI Codex (no human review before posting)



##########
airflow-core/src/airflow/dag_processing/processor.py:
##########
@@ -117,9 +119,28 @@ class DagFileParseRequest(BaseModel):
     """Bundle name for team-specific executor validation."""
 
     callback_requests: list[CallbackRequest] = Field(default_factory=list)
+
+    create_cron_data_intervals: bool = False
+    """``[scheduler] create_cron_data_intervals``.
+
+    A bundle cannot read the Airflow configuration, so the Dag processor sends 
the option with the
+    parse request, and the runtime builds the timetable that Python's 
``_create_timetable``
+    builds from the same schedule.
+    """
+
+    dag_default_timezone: str | int = "UTC"
+    """Encoded ``[core] default_timezone`` for a Dag without a 
``start_date``."""

Review Comment:
   The dedicated language-SDK request now contains a required 
`serialization_options: DagSerializationOptions` model. It groups 
`create_cron_data_intervals` and `default_timezone`, with neither field 
defaulted by the runtime. Downgrading to the `2026-06-16` supervisor schema 
removes the entire container.
   
   ---
   Drafted-by: OpenAI Codex (no human review before posting)



##########
airflow-core/src/airflow/dag_processing/processor.py:
##########
@@ -117,9 +119,28 @@ class DagFileParseRequest(BaseModel):
     """Bundle name for team-specific executor validation."""
 
     callback_requests: list[CallbackRequest] = Field(default_factory=list)
+
+    create_cron_data_intervals: bool = False
+    """``[scheduler] create_cron_data_intervals``.
+
+    A bundle cannot read the Airflow configuration, so the Dag processor sends 
the option with the
+    parse request, and the runtime builds the timetable that Python's 
``_create_timetable``
+    builds from the same schedule.
+    """
+
+    dag_default_timezone: str | int = "UTC"
+    """Encoded ``[core] default_timezone`` for a Dag without a 
``start_date``."""

Review Comment:
   The field documentation now specifies that `str` is an IANA timezone name 
(including `UTC`), while `int` is a fixed UTC offset in seconds. The 
serializers preserve that name-or-offset representation.
   
   ---
   Drafted-by: OpenAI Codex (no human review before posting)



##########
go-sdk/pkg/execution/genmodels/defaults.gen.go:
##########
@@ -79,6 +79,30 @@ func (m *DagCallbackRequest) DecodeMsgpack(dec 
*msgpack.Decoder) error {
        return nil
 }
 
+// DecodeMsgpack applies DagFileParseRequest's schema defaults that msgpack 
would otherwise skip.
+func (m *DagFileParseRequest) DecodeMsgpack(dec *msgpack.Decoder) error {
+       type alias DagFileParseRequest
+       v := alias{}
+       // Decode once into raw bytes so a nullable default applies only on an 
absent
+       // wire key, never overwriting an explicit null (both decode to nil).
+       var raw msgpack.RawMessage
+       if err := dec.Decode(&raw); err != nil {
+               return err
+       }
+       if err := msgpack.Unmarshal(raw, &v); err != nil {
+               return err
+       }
+       var present map[string]msgpack.RawMessage
+       if err := msgpack.Unmarshal(raw, &present); err != nil {
+               return err
+       }
+       if _, ok := present["dag_default_timezone"]; !ok {
+               v.DagDefaultTimezone = "UTC"
+       }

Review Comment:
   Core now resolves the scheduler flag and deployment timezone and sends both 
as required serialization options. Go, Java and TypeScript reject missing 
configuration instead of supplying runtime defaults. Explicit start dates 
retain precedence; the follow-up also handles Java `Instant` as UTC, with a 
regression test for both cron modes and non-UTC deployment defaults.
   
   ---
   Drafted-by: OpenAI Codex (no human review before posting)



##########
go-sdk/internal/bundle/task.go:
##########
@@ -65,10 +65,24 @@ type SerializedDag struct {
        Err   error
 }
 
+// DagSerializationOptions are the Airflow settings that the Dag processor 
sends with a parse
+// request. A bundle cannot read the Airflow config that Python's DAG reads, 
so the Dag processor
+// sends the settings that the serializer needs instead.
+type DagSerializationOptions struct {
+       // CreateCronDataIntervals is [scheduler] create_cron_data_intervals. 
Python's DAG builds a
+       // CronDataIntervalTimetable from a cron expression when it is set, and 
a CronTriggerTimetable
+       // when it is not.
+       CreateCronDataIntervals bool
+       // DefaultTimezone is Airflow's encoded [core] default_timezone. A Dag 
without a start date uses
+       // it as both its timezone and its cron timetable timezone. Nil 
represents the wire schema's
+       // default value, "UTC", for in-process callers.
+       DefaultTimezone any

Review Comment:
   Go now validates the wire timezone once at the `parseDags` boundary, then 
passes `bundle.Timezone` (an IANA name or fixed offset) to the serializer. 
Float, map, missing, invalid-name and out-of-range values are rejected before 
serialization. The runtime also embeds standard-library timezone data so valid 
names work in minimal images.
   
   ---
   Drafted-by: OpenAI Codex (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]

Reply via email to