diff --git a/airflow-core/docs/authoring-and-scheduling/dynamic-task-mapping.rst b/airflow-core/docs/authoring-and-scheduling/dynamic-task-mapping.rst index d9dfec21fe80e..d3a3f9cfa1d64 100644 --- a/airflow-core/docs/authoring-and-scheduling/dynamic-task-mapping.rst +++ b/airflow-core/docs/authoring-and-scheduling/dynamic-task-mapping.rst @@ -23,7 +23,7 @@ Dynamic Task Mapping Dynamic Task Mapping allows a way for a workflow to create a number of tasks at runtime based upon current data, rather than the Dag author having to know in advance how many tasks would be needed. -This is similar to defining your tasks in a for loop, but instead of having the DAG file fetch the data and do that itself, the scheduler can do this based on the output of a previous task. +This is similar to defining your tasks in a for loop, but instead of having the DAG file fetch the data and do that itself, the scheduler can do this based on the output of an upstream task. Unlike a Python for-loop executed at DAG parse time, dynamic task mapping defers task creation until runtime, allowing the scheduler to determine the exact number of task instances based on upstream task outputs. Right before a mapped task is executed the scheduler will create *n* copies of the task, one for each input. @@ -120,7 +120,7 @@ The ``make_list`` task runs as a normal task and must return a list or dict (see Repeated mapping ---------------- -The result of one mapped task can also be used as input to the next mapped task. +The result of one mapped task can also be used as input to the downstream mapped task. .. code-block:: python diff --git a/airflow-core/docs/best-practices.rst b/airflow-core/docs/best-practices.rst index eb7306b041b69..2a3be332d16b6 100644 --- a/airflow-core/docs/best-practices.rst +++ b/airflow-core/docs/best-practices.rst @@ -83,7 +83,7 @@ Communication -------------- Airflow executes tasks of a Dag on different servers in case you are using :doc:`Kubernetes executor ` or :doc:`Celery executor `. -Therefore, you should not store any file or config in the local filesystem as the next task is likely to run on a different server without access to it — for example, a task that downloads the data file that the next task processes. +Therefore, you should not store any file or config in the local filesystem as the downstream task is likely to run on a different server without access to it — for example, a task that downloads the data file that the downstream task processes. In the case of :class:`Local executor `, storing a file on disk can make retries harder e.g., your task requires a config file that is deleted by another task in Dag. @@ -815,7 +815,7 @@ Self-Checks ------------ You can also implement checks in a Dag to make sure the tasks are producing the results as expected. -As an example, if you have a task that pushes data to S3, you can implement a check in the next task. For example, the check could +As an example, if you have a task that pushes data to S3, you can implement a check in the downstream task. For example, the check could make sure that the partition is created in S3 and perform some simple checks to determine if the data is correct. diff --git a/airflow-core/docs/howto/dynamic-dag-generation.rst b/airflow-core/docs/howto/dynamic-dag-generation.rst index 407ea8e05b673..78c89db6ca849 100644 --- a/airflow-core/docs/howto/dynamic-dag-generation.rst +++ b/airflow-core/docs/howto/dynamic-dag-generation.rst @@ -22,7 +22,7 @@ Dynamic Dag Generation This document describes creation of Dags that have a structure generated dynamically, but where the number of tasks in the Dag does not change between Dag Runs. If you want to implement a Dag where number of Tasks (or -Task Groups as of Airflow 2.6) can change based on the output/result of previous tasks, see +Task Groups as of Airflow 2.6) can change based on the output/result of upstream tasks, see :doc:`/authoring-and-scheduling/dynamic-task-mapping`. .. note:: Consistent sequence of generating tasks and task groups diff --git a/airflow-core/docs/tutorial/objectstorage.rst b/airflow-core/docs/tutorial/objectstorage.rst index 0b8a890138fa9..36038a298182c 100644 --- a/airflow-core/docs/tutorial/objectstorage.rst +++ b/airflow-core/docs/tutorial/objectstorage.rst @@ -109,7 +109,7 @@ Here's what's happening: - Using ``ObjectStoragePath``, we write the data directly to cloud storage as Parquet This is a classic TaskFlow pattern. The object key changes each day, allowing us to run this daily and build a dataset -over time. We return the final object path to be used in the next task. +over time. We return the final object path to be used in the downstream task. Why this is cool: No boto3, no GCS client setup, no credentials juggling. Just simple file semantics that work across storage backends. @@ -133,7 +133,7 @@ A few key things to note: - We use ``path.fs`` to grab the right filesystem object and register it with DuckDB - Finally, we query the Parquet file using SQL and return a pandas DataFrame -Notice that the function doesn't recreate the path manually -- it gets the full path from the previous task using Xcom. +Notice that the function doesn't recreate the path manually -- it gets the full path from the upstream task using Xcom. This makes the task portable and decoupled from earlier logic. Bringing It All Together diff --git a/airflow-core/docs/tutorial/taskflow.rst b/airflow-core/docs/tutorial/taskflow.rst index 44187d7f4b8db..68cf89da61bbd 100644 --- a/airflow-core/docs/tutorial/taskflow.rst +++ b/airflow-core/docs/tutorial/taskflow.rst @@ -84,7 +84,7 @@ that Airflow can schedule and run. Here's the ``extract`` task: | -The function's return value is passed to the next task — no manual use of ``XComs`` required. Under the hood, TaskFlow +The function's return value is passed to the downstream task — no manual use of ``XComs`` required. Under the hood, TaskFlow uses ``XComs`` to manage data passing automatically, abstracting away the complexity of manual XCom management from the previous methods. You'll define ``transform`` and ``load`` tasks using the same pattern. diff --git a/providers/amazon/docs/operators/ssm.rst b/providers/amazon/docs/operators/ssm.rst index 317f62648b25a..874944b47385f 100644 --- a/providers/amazon/docs/operators/ssm.rst +++ b/providers/amazon/docs/operators/ssm.rst @@ -98,7 +98,7 @@ To retrieve the output and execution details from an SSM command that has been e This operator is useful for: -* Retrieving output from commands executed by :class:`~airflow.providers.amazon.aws.operators.ssm.SsmRunCommandOperator` in previous tasks +* Retrieving output from commands executed by :class:`~airflow.providers.amazon.aws.operators.ssm.SsmRunCommandOperator` in upstream tasks * Getting output from SSM commands executed outside of Airflow * Inspecting command results for debugging or data processing purposes @@ -108,7 +108,7 @@ To retrieve output from all instances that executed a command: get_all_output = SsmGetCommandInvocationOperator( task_id="get_command_output", - command_id='{{ ti.xcom_pull(task_ids="run_command") }}', # From previous task + command_id='{{ ti.xcom_pull(task_ids="run_command") }}', # From upstream task ) To retrieve output from a specific instance: