dstandish commented on a change in pull request #20150:
URL: https://github.com/apache/airflow/pull/20150#discussion_r765229343
##########
File path: docs/apache-airflow/concepts/deferring.rst
##########
@@ -109,13 +109,13 @@ There's also some design constraints to be aware of:
* The ``run`` method *must be asynchronous* (using Python's asyncio), and
correctly ``await`` whenever it does a blocking operation.
* ``run`` must ``yield`` its TriggerEvents, not return them. If it returns
before yielding at least one event, Airflow will consider this an error and
fail any Task Instances waiting on it. If it throws an exception, Airflow will
also fail any dependent task instances.
-* A Trigger *must be able to run in parallel* with other copies of itself.
This can happen both when two tasks defer based on the same trigger, and also
if a network partition happens and Airflow re-launches a trigger on a separated
machine.
+* You must assume that duplicates of your trigger instance may run
simultaneously. This can happen if a network partition happens and Airflow
re-launches a trigger on a separated machine.
Review comment:
How about:
> You must assume that your trigger instance may 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. E.g. you might
not want to use a trigger to insert database rows.
I think the "run more than once" makes it more obvious. That's really the
issue, more so than the question of timing i.e. running "in parallel" or
"simultaneously" etc.
lmkwyt
--
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]
