Trigger rules (all_success, one_success, none_failed) in Apache Airflow - Time & Space Complexity
When using trigger rules in Airflow, it's important to understand how the number of tasks affects the time it takes to decide if a task should run.
We want to know how the checking time grows as more tasks complete before the next task runs.
Analyze the time complexity of this Airflow task trigger rule check.
from airflow import DAG
from airflow.operators.dummy import DummyOperator
from airflow.utils.trigger_rule import TriggerRule
from datetime import datetime
dag = DAG('example_trigger_rule', start_date=datetime(2024, 1, 1))
start = DummyOperator(task_id='start', dag=dag)
check = DummyOperator(
task_id='check',
dag=dag,
trigger_rule=TriggerRule.ALL_SUCCESS
)
start >> check
This code sets a task with a trigger rule that waits for all upstream tasks to succeed before running.
When Airflow decides if the task can run, it checks the status of all upstream tasks.
- Primary operation: Checking each upstream task's state.
- How many times: Once per upstream task, so as many times as there are upstream tasks.
As the number of upstream tasks increases, the time to check their states grows proportionally.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | 10 checks |
| 100 | 100 checks |
| 1000 | 1000 checks |
Pattern observation: The checking time grows linearly with the number of upstream tasks.
Time Complexity: O(n)
This means the time to decide if a task runs grows directly with the number of upstream tasks it depends on.
[X] Wrong: "The trigger rule check happens instantly no matter how many tasks there are."
[OK] Correct: Each upstream task's state must be checked, so more tasks mean more checks and more time.
Understanding how trigger rules scale helps you design workflows that run efficiently and predictably as they grow.
What if the trigger rule was changed to one_success instead of all_success? How would the time complexity change?
Practice
Solution
Step 1: Understand the meaning of
This trigger rule requires every upstream task to complete successfully before the downstream task runs.all_successStep 2: Compare with other trigger rules
one_successruns if any upstream succeeds,none_failedruns if no upstream failed (some may be skipped), andall_failedruns only if all upstream failed.Final Answer:
all_success-> Option AQuick Check:
All upstream success =all_success[OK]
all_success [OK]- Confusing
one_successwithall_success - Thinking
none_failedmeans all succeeded - Assuming
all_failedruns on success
Solution
Step 1: Recall the trigger rule for running on any upstream success
The trigger ruleone_successruns the task if at least one upstream task succeeded.Step 2: Check syntax correctness
Settingtrigger_rule='one_success'is the correct syntax in Airflow task definition.Final Answer:
trigger_rule='one_success' -> Option DQuick Check:
At least one success = trigger_rule='one_success' [OK]
- Using
all_successinstead ofone_success - Misspelling trigger_rule or using wrong quotes
- Confusing
none_failedwithone_success
trigger_rule='none_failed', will it run?Solution
Step 1: Understand
This rule runs the task only if no upstream task has failed. If any upstream failed, it will not run.none_failedtrigger ruleStep 2: Analyze upstream task states
task3 failed, so the condition of no failures is false. Therefore, the downstream task will not run.Final Answer:
No, because one upstream task failed -> Option BQuick Check:
Any failure blocksnone_failedrun [OK]
none_failed won't run [OK]- Ignoring failed upstream tasks when using
none_failed - Confusing skipped with failed states
- Assuming
none_failedruns if some succeed
trigger_rule='one_success' but it never runs even though some upstream tasks succeed. What is the likely cause?Solution
Step 1: Check trigger_rule spelling and assignment
If the trigger_rule is misspelled or not properly set, Airflow defaults toall_success, causing the task not to run if not all upstream succeed.Step 2: Verify other conditions
Since some upstream succeed, and the task has dependencies, the most common cause is incorrect trigger_rule syntax.Final Answer:
The trigger_rule is misspelled or not set correctly -> Option CQuick Check:
Incorrect trigger_rule causes unexpected task skipping [OK]
- Assuming upstream failure when some succeeded
- Ignoring DAG paused state
- Not defining upstream dependencies
Solution
Step 1: Understand the requirement
The task should run if all upstream succeeded or if none failed but some were skipped. This means failures block the run, but skips do not.Step 2: Match with trigger rules
all_successrequires all succeed (no skips allowed).none_failedallows skips but no failures.one_successruns if any succeed, which is too loose.all_doneruns regardless of success or failure.Step 3: Choose the correct trigger rule
none_failedfits the requirement exactly.Final Answer:
none_failed-> Option AQuick Check:
No failures but allows skips =none_failed[OK]
none_failed to allow skips but no failures [OK]- Choosing
all_successwhich disallows skips - Using
one_successwhich is too permissive - Confusing
all_donewith failure conditions
Ready to prove it?
Pass the test and this pattern moves unknown
