Package Contents

class airflow.operators.BaseOperator(task_id, owner=configuration.conf.get('operators', 'DEFAULT_OWNER'), email=None, email_on_retry=True, email_on_failure=True, retries=0, retry_delay=timedelta(seconds=300), retry_exponential_backoff=False, max_retry_delay=None, start_date=None, end_date=None, schedule_interval=None, depends_on_past=False, wait_for_downstream=False, dag=None, params=None, default_args=None, priority_weight=1, weight_rule=WeightRule.DOWNSTREAM, queue=configuration.conf.get('celery', 'default_queue'), pool=None, sla=None, execution_timeout=None, on_failure_callback=None, on_success_callback=None, on_retry_callback=None, trigger_rule=TriggerRule.ALL_SUCCESS, resources=None, run_as_user=None, task_concurrency=None, executor_config=None, inlets=None, outlets=None, *args, **kwargs)[source]


Abstract base class for all operators. Since operators create objects that become nodes in the dag, BaseOperator contains many recursive methods for dag crawling behavior. To derive this class, you are expected to override the constructor as well as the ‘execute’ method.

Operators derived from this class should perform or trigger certain tasks synchronously (wait for completion). Example of operators could be an operator that runs a Pig job (PigOperator), a sensor operator that waits for a partition to land in Hive (HiveSensorOperator), or one that moves data from Hive to MySQL (Hive2MySqlOperator). Instances of these operators (tasks) target specific operations, running specific scripts, functions or data transfers.

This class is abstract and shouldn’t be instantiated. Instantiating a class derived from this one results in the creation of a task object, which ultimately becomes a node in DAG objects. Task dependencies should be set by using the set_upstream and/or set_downstream methods.

  • task_id (str) – a unique, meaningful id for the task

  • owner (str) – the owner of the task, using the unix username is recommended

  • retries (int) – the number of retries that should be performed before failing the task

  • retry_delay (datetime.timedelta) – delay between retries

  • retry_exponential_backoff (bool) – allow progressive longer waits between retries by using exponential backoff algorithm on retry delay (delay will be converted into seconds)

  • max_retry_delay (datetime.timedelta) – maximum delay interval between retries

  • start_date (datetime.datetime) – The start_date for the task, determines the execution_date for the first task instance. The best practice is to have the start_date rounded to your DAG’s schedule_interval. Daily jobs have their start_date some day at 00:00:00, hourly jobs have their start_date at 00:00 of a specific hour. Note that Airflow simply looks at the latest execution_date and adds the schedule_interval to determine the next execution_date. It is also very important to note that different tasks’ dependencies need to line up in time. If task A depends on task B and their start_date are offset in a way that their execution_date don’t line up, A’s dependencies will never be met. If you are looking to delay a task, for example running a daily task at 2AM, look into the TimeSensor and TimeDeltaSensor. We advise against using dynamic start_date and recommend using fixed ones. Read the FAQ entry about start_date for more information.

  • end_date (datetime.datetime) – if specified, the scheduler won’t go beyond this date

  • depends_on_past (bool) – when set to true, task instances will run sequentially while relying on the previous task’s schedule to succeed. The task instance for the start_date is allowed to run.

  • wait_for_downstream (bool) – when set to true, an instance of task X will wait for tasks immediately downstream of the previous instance of task X to finish successfully before it runs. This is useful if the different instances of a task X alter the same asset, and this asset is used by tasks downstream of task X. Note that depends_on_past is forced to True wherever wait_for_downstream is used.

  • queue (str) – which queue to target when running this job. Not all executors implement queue management, the CeleryExecutor does support targeting specific queues.

  • dag (airflow.models.DAG) – a reference to the dag the task is attached to (if any)

  • priority_weight (int) – priority weight of this task against other task. This allows the executor to trigger higher priority tasks before others when things get backed up.

  • weight_rule (str) – weighting method used for the effective total priority weight of the task. Options are: { downstream | upstream | absolute } default is downstream When set to downstream the effective weight of the task is the aggregate sum of all downstream descendants. As a result, upstream tasks will have higher weight and will be scheduled more aggressively when using positive weight values. This is useful when you have multiple dag run instances and desire to have all upstream tasks to complete for all runs before each dag can continue processing downstream tasks. When set to upstream the effective weight is the aggregate sum of all upstream ancestors. This is the opposite where downtream tasks have higher weight and will be scheduled more aggressively when using positive weight values. This is useful when you have multiple dag run instances and prefer to have each dag complete before starting upstream tasks of other dags. When set to absolute, the effective weight is the exact priority_weight specified without additional weighting. You may want to do this when you know exactly what priority weight each task should have. Additionally, when set to absolute, there is bonus effect of significantly speeding up the task creation process as for very large DAGS. Options can be set as string or using the constants defined in the static class airflow.utils.WeightRule

  • pool (str) – the slot pool this task should run in, slot pools are a way to limit concurrency for certain tasks

  • sla (datetime.timedelta) – time by which the job is expected to succeed. Note that this represents the timedelta after the period is closed. For example if you set an SLA of 1 hour, the scheduler would send an email soon after 1:00AM on the 2016-01-02 if the 2016-01-01 instance has not succeeded yet. The scheduler pays special attention for jobs with an SLA and sends alert emails for sla misses. SLA misses are also recorded in the database for future reference. All tasks that share the same SLA time get bundled in a single email, sent soon after that time. SLA notification are sent once and only once for each task instance.

  • execution_timeout (datetime.timedelta) – max time allowed for the execution of this task instance, if it goes beyond it will raise and fail.

  • on_failure_callback (callable) – a function to be called when a task instance of this task fails. a context dictionary is passed as a single parameter to this function. Context contains references to related objects to the task instance and is documented under the macros section of the API.

  • on_retry_callback (callable) – much like the on_failure_callback except that it is executed when retries occur.

  • on_success_callback (callable) – much like the on_failure_callback except that it is executed when the task succeeds.

  • trigger_rule (str) – defines the rule by which dependencies are applied for the task to get triggered. Options are: { all_success | all_failed | all_done | one_success | one_failed | none_failed | none_skipped | dummy} default is all_success. Options can be set as string or using the constants defined in the static class airflow.utils.TriggerRule

  • resources (dict) – A map of resource parameter names (the argument names of the Resources constructor) to their values.

  • run_as_user (str) – unix username to impersonate while running the task

  • task_concurrency (int) – When set, a task will be able to limit the concurrent runs across execution_dates

  • executor_config (dict) –

    Additional task-level configuration parameters that are interpreted by a specific executor. Parameters are namespaced by the name of executor.

    Example: to run this task in a specific docker container through the KubernetesExecutor

            {"image": "myCustomDockerImage"}

template_fields = []
template_ext = []
ui_color = #fff
ui_fgcolor = #000
_base_operator_shallow_copy_attrs = ['user_defined_macros', 'user_defined_filters', 'params', '_log']
shallow_copy_attrs = []

Returns the Operator’s DAG if set, otherwise raises an error


Returns the list of dependencies for the operator. These differ from execution context dependencies in that they are specific to tasks and can be extended/overridden by subclasses.


The schedule interval of the DAG always wins over individual tasks so that tasks within a DAG always line up. The task still needs a schedule_interval as it may not be attached to a DAG.


@property: list of tasks directly upstream


@property: list of tasks directly downstream

__eq__(self, other)
__ne__(self, other)
__lt__(self, other)
__rshift__(self, other)

Implements Self >> Other == self.set_downstream(other)

If “Other” is a DAG, the DAG is assigned to the Operator.

__lshift__(self, other)

Implements Self << Other == self.set_upstream(other)

If “Other” is a DAG, the DAG is assigned to the Operator.

__rrshift__(self, other)

Called for [DAG] >> [Operator] because DAGs don’t have __rshift__ operators.

__rlshift__(self, other)

Called for [DAG] << [Operator] because DAGs don’t have __lshift__ operators.


Returns True if the Operator has been assigned to a DAG.

pre_execute(self, context)

This hook is triggered right before self.execute() is called.

execute(self, context)

This is the main method to derive when creating an operator. Context is the same dictionary used as when rendering jinja templates.

Refer to get_template_context for more context.

post_execute(self, context, result=None)

This hook is triggered right after self.execute() is called. It is passed the execution context and any results returned by the operator.


Override this method to cleanup subprocesses when a task instance gets killed. Any use of the threading, subprocess or multiprocessing module within an operator needs to be cleaned up or it will leave ghost processes behind.

__deepcopy__(self, memo)

Hack sorting double chained task lists by task_id to avoid hitting max_depth on deepcopy operations.

__setstate__(self, state)
render_template_from_field(self, attr, content, context, jinja_env)

Renders a template from a field. If the field is a string, it will simply render the string and return the result. If it is a collection or nested set of collections, it will traverse the structure and render all elements in it. If the field has another type, it will return it as it is.

render_template(self, attr, content, context)

Renders a template either from a file or directly in a field, and returns the rendered result.


Hook that is triggered after the templated fields get replaced by their content. If you need your operator to alter the content of the file before the template is rendered, it should override this method to do so.

clear(self, start_date=None, end_date=None, upstream=False, downstream=False, session=None)

Clears the state of task instances associated with the task, following the parameters specified.

get_task_instances(self, session, start_date=None, end_date=None)

Get a set of task instance related to this task for a specific date range.

get_flat_relative_ids(self, upstream=False, found_descendants=None)

Get a flat list of relatives’ ids, either upstream or downstream.

get_flat_relatives(self, upstream=False)

Get a flat list of relatives, either upstream or downstream.

run(self, start_date=None, end_date=None, ignore_first_depends_on_past=False, ignore_ti_state=False, mark_success=False)

Run a set of task instances for a date range.

get_direct_relative_ids(self, upstream=False)

Get the direct relative ids to the current task, upstream or downstream.

get_direct_relatives(self, upstream=False)

Get the direct relatives to the current task, upstream or downstream.

add_only_new(self, item_set, item)
_set_relatives(self, task_or_task_list, upstream=False)
set_downstream(self, task_or_task_list)

Set a task or a task list to be directly downstream from the current task.

set_upstream(self, task_or_task_list)

Set a task or a task list to be directly upstream from the current task.

xcom_push(self, context, key, value, execution_date=None)

See TaskInstance.xcom_push()

xcom_pull(self, context, task_ids=None, dag_id=None, key=XCOM_RETURN_KEY, include_prior_dates=None)

See TaskInstance.xcom_pull()


Integrate plugins to the context