jscheffl commented on code in PR #52053: URL: https://github.com/apache/airflow/pull/52053#discussion_r2183759002
########## providers/standard/src/airflow/providers/standard/operators/hitl.py: ########## @@ -0,0 +1,205 @@ +# Licensed to the Apache Software Foundation (ASF) under one +# or more contributor license agreements. See the NOTICE file +# distributed with this work for additional information +# regarding copyright ownership. The ASF licenses this file +# to you under the Apache License, Version 2.0 (the +# "License"); you may not use this file except in compliance +# with the License. You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, +# software distributed under the License is distributed on an +# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY +# KIND, either express or implied. See the License for the +# specific language governing permissions and limitations +# under the License. +from __future__ import annotations + +import logging +from collections.abc import Sequence +from datetime import datetime, timezone +from typing import TYPE_CHECKING, Any + +from airflow.models import SkipMixin +from airflow.models.baseoperator import BaseOperator +from airflow.providers.standard.exceptions import HITLTriggerEventError +from airflow.providers.standard.execution_time.hitl import add_hitl_input_request +from airflow.providers.standard.triggers.hitl import HITLTrigger +from airflow.providers.standard.version_compat import AIRFLOW_V_3_1_PLUS +from airflow.sdk.definitions.param import ParamsDict + +if TYPE_CHECKING: + from airflow.sdk.definitions.context import Context + +log = logging.getLogger(__name__) +if not AIRFLOW_V_3_1_PLUS: + log.warning("Human in the loop functionality needs Airflow 3.1+..") + + +class HITLOperator(BaseOperator): Review Comment: As you asked for feedback - also as discussed in Airflow 3 Devcall today: - I would have favored to keep HITL funtions completely outside of core in a separate provider that implements all via API, DB models and plugins w/o touching SDK and core. - There were other opinions in majority in the call be raised which all a reasonable and I can accept - So I will not block if this is deeply integrated into DB model or core, SDK and standard provider - I see still a risk that DB model and Provider package will then have a tight coupling - Also a bit of complexity is needed to hide/disable the HITL function for cases where standard provider is deployed in Airflow 2.x or 3.0.x (Which would be for me the reason to separate this out of standard provider to directly model and define the dependency in pyproject toml) But overall I am very happy that you took over the first integration and are driving this AIP as personally I have currently not sufficient time to make it myself (even though AIP author) - and I am happy if the function is there. If it is not according to my design I will not block it if the majority of other contributors vote for other technical architecture. 50% matter of taste and 50% technical risk I mentioned and assume we can also live with this. Note: Might be easier to start a new branch from main and selectively take over code from PR rather than base another branch from here? But would leave it up to you. -- 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]
