jason810496 commented on code in PR #76803: URL: https://github.com/apache/airflow/pull/76803#discussion_r4535622620
########## airflow-core/adr/lang-sdk/0017-task-loops-across-lang-sdks.md: ########## @@ -38,9 +38,9 @@ Proposed. ## Decision 1. **Iteration creation stays in core for every language.** Regions, instance creation, rerun trajectories and the scope of every XCom read are core's. An SDK emits a loop group and runs one callable; it never creates an instance and never decides which iteration a read belongs to. -2. **A loop is a task group with four more serialized fields** — `max_iterations`, `has_until`, `terminal_task_id` and `gate_task_id`. The gate is found by `gate_task_id` and never by an operator class name, which [ADR-0007](0007-taskflow-across-language-boundary.md) decision B already rejected: a gate emitted by another SDK cannot honestly claim `LoopGateOperator`. +2. **A loop is a task group with four more serialized fields** — `max_iterations`, `has_until`, `terminal_task_id` and `gate_task_id`. Core finds the gate by its operator name, `LoopGateOperator`, as it finds Python's, so every SDK serializes its gate with `task_type: "LoopGateOperator"` and core's gate handling stays as it is. This is the one exception to [ADR-0007](0007-taskflow-across-language-boundary.md) decision B: the name says what core does with the task, not which class runs it. Review Comment: I intentionally step back and just rely on checking against the `LoopGateOperator` to keep the the core path as simple as possible. -- 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]
