This is an automated email from the ASF dual-hosted git repository. ephraimanierobi pushed a commit to branch v2-9-test in repository https://gitbox.apache.org/repos/asf/airflow.git
commit c2f93bdefdddc96d5ca193e305a90690a8f64e50 Author: Elad Kalif <[email protected]> AuthorDate: Mon May 6 17:05:20 2024 +0300 Update note about restarting triggerer proccess (#39436) * Add note about Trigger reload * fix (cherry picked from commit 0f9ad981c3a2b6cdd82377d19022a9216d663d60) --- docs/apache-airflow/authoring-and-scheduling/deferring.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/apache-airflow/authoring-and-scheduling/deferring.rst b/docs/apache-airflow/authoring-and-scheduling/deferring.rst index b9e3046731..bd759c2c0a 100644 --- a/docs/apache-airflow/authoring-and-scheduling/deferring.rst +++ b/docs/apache-airflow/authoring-and-scheduling/deferring.rst @@ -58,7 +58,6 @@ When writing a deferrable operators these are the main points to consider: * Your operator will be stopped and removed from its worker while deferred, and no state persists automatically. You can persist state by instructing Airflow to resume the operator at a certain method or by passing certain kwargs. * You can defer multiple times, and you can defer before or after your operator does significant work. Or, you can defer if certain conditions are met. For example, if a system does not have an immediate answer. Deferral is entirely under your control. * Any operator can defer; no special marking on its class is needed, and it's not limited to sensors. -* In order for any changes to a trigger to be reflected, the *triggerer* needs to be restarted whenever the trigger is modified. * If you want to add an operator or sensor that supports both deferrable and non-deferrable modes, it's suggested to add ``deferrable: bool = conf.getboolean("operators", "default_deferrable", fallback=False)`` to the ``__init__`` method of the operator and use it to decide whether to run the operator in deferrable mode. You can configure the default value of ``deferrable`` for all the operators and sensors that support switching between deferrable and non-deferrable mode through ``defau [...] .. code-block:: python @@ -157,6 +156,7 @@ There's some design constraints to be aware of when writing your own trigger: * You should assume that a trigger instance can run *more than once*. This can happen if a network partition occurs and Airflow re-launches a trigger on a separated machine. So, you must be mindful about side effects. For example you might not want to use a trigger to insert database rows. * If your trigger is designed to emit more than one event (not currently supported), then each emitted event *must* contain a payload that can be used to deduplicate events if the trigger is running in multiple places. If you only fire one event and don't need to pass information back to the operator, you can just set the payload to ``None``. * A trigger can suddenly be removed from one triggerer service and started on a new one. For example, if subnets are changed and a network partition results or if there is a deployment. If desired, you can implement the ``cleanup`` method, which is always called after ``run``, whether the trigger exits cleanly or otherwise. +* In order for any changes to a trigger to be reflected, the *triggerer* needs to be restarted whenever the trigger is modified. .. note::
