airflow-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <>
Subject [GitHub] [airflow] JonnyIncognito commented on a change in pull request #6210: [AIRFLOW-5567] BaseAsyncOperator
Date Wed, 16 Oct 2019 23:24:16 GMT
JonnyIncognito commented on a change in pull request #6210: [AIRFLOW-5567] BaseAsyncOperator

 File path: airflow/models/
 @@ -0,0 +1,161 @@
+# -*- coding: utf-8 -*-
+# 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
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# KIND, either express or implied.  See the License for the
+# specific language governing permissions and limitations
+# under the License.
+Base Asynchronous Operator for kicking off a long running
+operations and polling for completion with reschedule mode.
+from abc import abstractmethod
+from typing import Dict, List, Optional, Union
+from airflow.models import SkipMixin, TaskReschedule
+from airflow.models.xcom import XCOM_EXTERNAL_RESOURCE_ID_KEY
+from airflow.sensors.base_sensor_operator import BaseSensorOperator
+from airflow.utils.decorators import apply_defaults
 Review comment:
   > XCOM data appears to be cleared at start of each task. [See here](
   > So when task restarts after reschedule, we lose the resource id.
   Ouch, that is quite a limitation for using XCom. Is there anywhere else to store task state?
If not, some options:
   1. Use `mode='poke'`, at the expense of using up a task slot for long-running tasks. Not
ideal, but gets "correct" behaviour. It'd then be "atomic" rather than "async" behaviour.
   1. Enhance `TaskInstance` to make clearing XCom data conditional by delegating it to the
task/operator. There could be a new function like `BaseOperator.pre_execute_clear_state()`
which can be overridden by implementers. `BaseOperator` is already aware of / coupled with
`TaskInstance`, so I don't think we'd be breaking separation of concerns any more than it
already is?
   1. There might be enough justification to say that for rescheduled tasks (i.e. transition
from `State.UP_FOR_RESCHEDULE` to `State.RUNNING`) then `TaskInstance` shouldn't clear XCom.
The call to `run()` -> `_check_and_change_state_before_execution()` does know about this
state change, but I see in the code that there are places which bypass the call to `run()`
and go directly to `_run_raw_task()` (e.g. the CLI).

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.
For queries about this service, please contact Infrastructure at:

With regards,
Apache Git Services

View raw message