This is an automated email from the ASF dual-hosted git repository.
eladkal pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/airflow.git
The following commit(s) were added to refs/heads/main by this push:
new a050861fc59 Fix documentation misusing previous/next for task
relationships (#69179)
a050861fc59 is described below
commit a050861fc59193347a60d6ab306a5e0a03c719a7
Author: PoAn Yang <[email protected]>
AuthorDate: Wed Jul 8 04:33:45 2026 +0900
Fix documentation misusing previous/next for task relationships (#69179)
Signed-off-by: PoAn Yang <[email protected]>
---
airflow-core/docs/authoring-and-scheduling/dynamic-task-mapping.rst | 4 ++--
airflow-core/docs/best-practices.rst | 4 ++--
airflow-core/docs/howto/dynamic-dag-generation.rst | 2 +-
airflow-core/docs/tutorial/objectstorage.rst | 4 ++--
airflow-core/docs/tutorial/taskflow.rst | 2 +-
providers/amazon/docs/operators/ssm.rst | 4 ++--
6 files changed, 10 insertions(+), 10 deletions(-)
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 d9dfec21fe8..d3a3f9cfa1d 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 5ddcb81edaf..8aa46d2da84 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
<apache-airflow-providers-cncf-kubernetes:kubernetes_executor>` or :doc:`Celery
executor <apache-airflow-providers-celery: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
<airflow.executors.local_executor.LocalExecutor>`,
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 407ea8e05b6..78c89db6ca8 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 0b8a890138f..36038a29818 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 44187d7f4b8..68cf89da61b 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 317f62648b2..874944b4738 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:
