Atomic operations in pipelines in Apache Airflow - Commands & Configuration

Introduction

Sometimes, when running a series of tasks in a pipeline, you want to make sure that either all tasks succeed or none do. Atomic operations help by making the whole set of tasks behave like one single step that fully completes or fully fails, avoiding partial results.

When you want to load data into a database only if all data files are processed successfully.

When you need to update multiple systems and want to avoid partial updates that cause inconsistency.

When running a multi-step data transformation where failure in one step means the whole process should be retried.

When you want to ensure that temporary files are cleaned up only if all previous tasks succeed.

When you want to avoid triggering downstream tasks if any upstream task fails.

Config File - atomic_pipeline_dag.py

atomic_pipeline_dag.py

from airflow import DAG
from airflow.operators.python import PythonOperator
from airflow.utils.dates import days_ago

def task1():
    print("Task 1 completed")

def task2():
    print("Task 2 completed")

def task3():
    print("Task 3 completed")

with DAG(
    dag_id='atomic_pipeline',
    start_date=days_ago(1),
    schedule_interval=None,
    catchup=False
) as dag:

    t1 = PythonOperator(
        task_id='task1',
        python_callable=task1
    )

    t2 = PythonOperator(
        task_id='task2',
        python_callable=task2
    )

    t3 = PythonOperator(
        task_id='task3',
        python_callable=task3
    )

    t1 >> t2 >> t3

This Airflow DAG defines three tasks that run one after another.

The tasks are simple Python functions printing messages.

The order t1 >> t2 >> t3 ensures they run sequentially.

If any task fails, the next tasks will not run, making the pipeline atomic in behavior.

Commands

List all available DAGs to confirm the new atomic_pipeline DAG is recognized by Airflow.

Terminal

airflow dags list

Expected Output

dag_id          | filepath

atomic_pipeline | /usr/local/airflow/dags/atomic_pipeline_dag.py

example_bash_operator | /usr/local/airflow/dags/example_bash_operator.py

Trigger the atomic_pipeline DAG to start running the tasks in order.

Terminal

airflow dags trigger atomic_pipeline

Expected Output

Created <DagRun atomic_pipeline @ 2024-06-01T12:00:00+00:00: manual__2024-06-01T12:00:00+00:00, externally triggered: True>

List all tasks in the atomic_pipeline DAG to see the steps that will run.

Terminal

airflow tasks list atomic_pipeline

Expected Output

task1

task2

task3

Run task2 alone for the given date to test it independently without running the full DAG.

Terminal

airflow tasks test atomic_pipeline task2 2024-06-01

Expected Output

[2024-06-01 12:00:00,000] {taskinstance.py:xxxx} INFO - Executing <Task(PythonOperator): task2> on 2024-06-01

Task 2 completed

[2024-06-01 12:00:00,100] {taskinstance.py:xxxx} INFO - Marking task as SUCCESS. dag_id=atomic_pipeline, task_id=task2, execution_date=2024-06-01

Key Concept

If you remember nothing else from this pattern, remember: chaining tasks with dependencies ensures the pipeline behaves atomically by stopping on failure.

Common Mistakes

Not setting task dependencies, so tasks run in parallel and partial results happen.

Without dependencies, tasks do not wait for each other, so failures in one task do not stop others, breaking atomicity.

Always define task order using >> or set_upstream/set_downstream to enforce sequential execution.

Ignoring task failures and manually marking tasks as success.

This hides real errors and causes downstream tasks to run even if previous steps failed.

Let Airflow handle task states automatically and fix errors instead of forcing success.

Summary

Define tasks as PythonOperators or other operators in an Airflow DAG.

Set task dependencies to run tasks sequentially for atomic behavior.

Trigger the DAG and monitor task execution to ensure all tasks succeed or the pipeline stops.

Practice

1. What does it mean for a task in an Airflow pipeline to be atomic?

easy

A. The task can be skipped without affecting the pipeline

B. The task runs multiple times in parallel

C. The task either completes fully or does not change anything at all

D. The task runs only once per day

Solution

1. Step 1: Understand atomicity in pipelines

   Atomic means an operation is indivisible: it either fully happens or not at all.

2. Step 2: Apply this to Airflow tasks

   In Airflow, atomic tasks ensure no partial changes if they fail.

3. Final Answer:

   The task either completes fully or does not change anything at all -> Option C

4. Quick Check:

   Atomic = all or nothing [OK]

Hint: Atomic means all or nothing for task completion [OK]

Common Mistakes:

• Thinking atomic means running multiple times
• Confusing atomic with task scheduling frequency
• Assuming atomic means task can be skipped

2. Which of the following is the correct way to define a PythonOperator task in Airflow to ensure atomicity?

easy

A. task = PythonOperator(task_id='task1', python_callable=my_func, retry=3)

B. task = PythonOperator(task_id='task1', python_callable=my_func, retries='three')

C. task = PythonOperator(task_id='task1', python_callable=my_func, retry_count=3)

D. task = PythonOperator(task_id='task1', python_callable=my_func, retries=3)

Solution

1. Step 1: Check PythonOperator parameters

   The correct parameter for retry attempts is retries with an integer value.

2. Step 2: Validate each option

   task = PythonOperator(task_id='task1', python_callable=my_func, retries=3) uses retries=3 correctly. Options A, B, and D use wrong parameter names or types.

3. Final Answer:

   task = PythonOperator(task_id='task1', python_callable=my_func, retries=3) -> Option D

4. Quick Check:

   Correct retries param = task = PythonOperator(task_id='task1', python_callable=my_func, retries=3) [OK]

Hint: Use 'retries' with integer for retry count [OK]

Common Mistakes:

• Using string instead of integer for retries
• Using incorrect parameter names like retry or retry_count
• Missing retries parameter for retry logic

3. Given this Airflow task code snippet, what will be the output if my_task fails on first try but succeeds on retry?

task = PythonOperator(
    task_id='my_task',
    python_callable=my_func,
    retries=1,
    retry_delay=timedelta(seconds=5)
)

medium

A. Task fails and pipeline stops immediately

B. Task retries once after 5 seconds and then succeeds

C. Task retries infinitely until success

D. Task skips retry and marks success

Solution

1. Step 1: Understand retries and retry_delay

   Retries=1 means one retry attempt after failure, retry_delay=5 seconds means wait 5 seconds before retry.

2. Step 2: Apply to task behavior

   If first try fails, Airflow waits 5 seconds and retries once. If retry succeeds, task is marked success.

3. Final Answer:

   Task retries once after 5 seconds and then succeeds -> Option B

4. Quick Check:

   Retries=1 means one retry attempt [OK]

Hint: Retries=1 means one retry after delay [OK]

Common Mistakes:

• Assuming no retry happens
• Thinking retries means infinite retries
• Ignoring retry_delay effect

4. You wrote a task that updates a database but sometimes leaves partial updates if it fails. What is the best way to fix this atomicity issue?

medium

A. Add database transactions inside the task to commit or rollback changes

B. Increase the task timeout to avoid failures

C. Remove retries to prevent repeated partial updates

D. Split the task into multiple smaller tasks without transactions

Solution

1. Step 1: Identify cause of partial updates

   Partial updates happen if database changes are not atomic, meaning no transaction control.

2. Step 2: Apply database transactions

   Using transactions ensures all changes commit together or rollback on failure, fixing atomicity.

3. Final Answer:

   Add database transactions inside the task to commit or rollback changes -> Option A

4. Quick Check:

   Transactions ensure atomic DB updates [OK]

Hint: Use DB transactions to ensure all-or-nothing updates [OK]

Common Mistakes:

• Thinking increasing timeout fixes atomicity
• Removing retries causes no atomicity improvement
• Splitting tasks without transactions still risks partial updates

5. You want to ensure a pipeline task that writes files to cloud storage is atomic. Which approach best guarantees no partial files remain if the task fails?

hard

A. Write files to a temporary location first, then move them to final location after success

B. Write files directly to final location and delete on failure manually

C. Write files without retries to avoid duplicates

D. Write files in parallel to speed up the task

Solution

1. Step 1: Understand atomic file writes

   Writing directly risks partial files if failure occurs mid-write.

2. Step 2: Use temporary location and move

   Writing to temp location then moving is atomic because move is usually instant and atomic, avoiding partial files in final location.

3. Final Answer:

   Write files to a temporary location first, then move them to final location after success -> Option A

4. Quick Check:

   Temp write + move = atomic file update [OK]

Hint: Write temp files then move to final location atomically [OK]

Common Mistakes:

• Writing directly risks partial files
• Deleting on failure is error-prone
• Skipping retries does not guarantee atomicity
• Parallel writes do not ensure atomic single file