This is an automated email from the ASF dual-hosted git repository.
turaga 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 e7898b8100f Fix duplicate words in airflow-core documentation (#62384)
e7898b8100f is described below
commit e7898b8100f92f1988edc35188339e37922813da
Author: Keisuke Kawamura <[email protected]>
AuthorDate: Tue Feb 24 11:45:30 2026 +0900
Fix duplicate words in airflow-core documentation (#62384)
Remove repeated words ("is is", "the the", "this this", "set set",
"how how") and an extra article ("the a") across 8 documentation files.
Co-authored-by: keisuke-kawamura <[email protected]>
Co-authored-by: Claude Opus 4.6 <[email protected]>
---
airflow-core/docs/administration-and-deployment/dagfile-processing.rst | 2 +-
airflow-core/docs/authoring-and-scheduling/assets.rst | 2 +-
airflow-core/docs/authoring-and-scheduling/deferring.rst | 2 +-
airflow-core/docs/authoring-and-scheduling/timetable.rst | 2 +-
airflow-core/docs/core-concepts/executor/index.rst | 2 +-
airflow-core/docs/core-concepts/objectstorage.rst | 2 +-
airflow-core/docs/howto/connection.rst | 2 +-
airflow-core/docs/installation/upgrading.rst | 2 +-
8 files changed, 8 insertions(+), 8 deletions(-)
diff --git
a/airflow-core/docs/administration-and-deployment/dagfile-processing.rst
b/airflow-core/docs/administration-and-deployment/dagfile-processing.rst
index d2050e1df6a..b83c72171a2 100644
--- a/airflow-core/docs/administration-and-deployment/dagfile-processing.rst
+++ b/airflow-core/docs/administration-and-deployment/dagfile-processing.rst
@@ -120,7 +120,7 @@ There are several areas of resource usage that you should
pay attention to:
* Another solution to FileSystem performance, if it becomes your bottleneck,
is to turn to alternative
mechanisms of distributing your Dags. Embedding Dags in your image and
GitSync distribution have both
the property that the files are available locally for the Dag processor and
it does not have to use a
- distributed filesystem to read the files, the files are available locally
for the the Dag processor and it is
+ distributed filesystem to read the files, the files are available locally
for the Dag processor and it is
usually as fast as it can be, especially if your machines use fast SSD disks
for local storage. Those
distribution mechanisms have other characteristics that might make them not
the best choice for you,
but if your problems with performance come from distributed filesystem
performance, they might be the
diff --git a/airflow-core/docs/authoring-and-scheduling/assets.rst
b/airflow-core/docs/authoring-and-scheduling/assets.rst
index de5913a59e8..b5b97b9979c 100644
--- a/airflow-core/docs/authoring-and-scheduling/assets.rst
+++ b/airflow-core/docs/authoring-and-scheduling/assets.rst
@@ -63,7 +63,7 @@ For pre-defined schemes (e.g., ``file``, ``postgres``, and
``s3``), you must pro
# invalid asset:
must_contain_bucket_name = Asset("s3://")
-Do not use the ``airflow`` scheme, which is is reserved for Airflow's
internals.
+Do not use the ``airflow`` scheme, which is reserved for Airflow's internals.
Airflow always prefers using lower cases in schemes, and case sensitivity is
needed in the host part of the URI to correctly distinguish between resources.
diff --git a/airflow-core/docs/authoring-and-scheduling/deferring.rst
b/airflow-core/docs/authoring-and-scheduling/deferring.rst
index 1cfa2384144..9344f07aa60 100644
--- a/airflow-core/docs/authoring-and-scheduling/deferring.rst
+++ b/airflow-core/docs/authoring-and-scheduling/deferring.rst
@@ -506,7 +506,7 @@ Additionally, queue assignment is currently only compatible
with the subset of t
+------------------------------------------------------------------------------------------------------+----------------------+----------------------------------------------------------------------------------+
| Trigger Type
| Supports queues? | Triggerer assignment when
:ref:`config:triggerer__queues_enabled` is ``True`` |
+======================================================================================================+======================+==================================================================================+
-| Task-created Trigger instances
| Yes | Any triggerer with the the
task queue present in its ``--queues`` option |
+| Task-created Trigger instances
| Yes | Any triggerer with the task
queue present in its ``--queues`` option |
+------------------------------------------------------------------------------------------------------+----------------------+----------------------------------------------------------------------------------+
| :doc:`Event-Driven Triggers<../authoring-and-scheduling/event-scheduling>`
| No | Any triggerer running without
the ``--queues`` option |
+------------------------------------------------------------------------------------------------------+----------------------+----------------------------------------------------------------------------------+
diff --git a/airflow-core/docs/authoring-and-scheduling/timetable.rst
b/airflow-core/docs/authoring-and-scheduling/timetable.rst
index e92fc66130e..28957370a47 100644
--- a/airflow-core/docs/authoring-and-scheduling/timetable.rst
+++ b/airflow-core/docs/authoring-and-scheduling/timetable.rst
@@ -325,7 +325,7 @@ By default, ``catchup`` is set to ``False``. This prevents
running unnecessary D
- If you create a new Dag with a start date in the past, and don't want to run
Dags for the past. If ``catchup`` is ``True``, Airflow runs all Dags that would
have run in that time interval.
- If you pause an existing Dag, and then restart it at a later date,
``catchup`` being ``False`` means that Airflow does not run the Dags that would
have run during the paused period.
-In these scenarios, the ``logical_date`` in the ``run_id`` are based on how
how the timetable handles the data
+In these scenarios, the ``logical_date`` in the ``run_id`` are based on how
the timetable handles the data
interval.
You can change the default ``catchup`` behavior using the Airflow config
``[scheduler] catchup_by_default``.
diff --git a/airflow-core/docs/core-concepts/executor/index.rst
b/airflow-core/docs/core-concepts/executor/index.rst
index e3178bb48e2..3a0d593a49b 100644
--- a/airflow-core/docs/core-concepts/executor/index.rst
+++ b/airflow-core/docs/core-concepts/executor/index.rst
@@ -354,7 +354,7 @@ Logging
^^^^^^^
Executors may vend log messages which will be included in the Airflow task
logs by implementing the ``get_task_logs`` method. This can be helpful if the
execution environment has extra context in the case of task failures, which may
be due to the execution environment itself rather than the Airflow task code.
It can also be helpful to include setup/teardown logging from the execution
environment.
-The ``KubernetesExecutor`` leverages this this capability to include logs from
the pod which ran a specific Airflow task and display them in the logs for that
Airflow task. A pseudo-code example of implementing task log vending from an
executor can be seen below:
+The ``KubernetesExecutor`` leverages this capability to include logs from the
pod which ran a specific Airflow task and display them in the logs for that
Airflow task. A pseudo-code example of implementing task log vending from an
executor can be seen below:
.. code-block:: python
diff --git a/airflow-core/docs/core-concepts/objectstorage.rst
b/airflow-core/docs/core-concepts/objectstorage.rst
index 4478980aeda..aabdd019060 100644
--- a/airflow-core/docs/core-concepts/objectstorage.rst
+++ b/airflow-core/docs/core-concepts/objectstorage.rst
@@ -314,7 +314,7 @@ External Integrations
---------------------
Many other projects, like DuckDB, Apache Iceberg etc, can make use of the
object storage abstraction. Often this is
-done by passing the underlying ``fsspec`` implementation. For this this
purpose ``ObjectStoragePath`` exposes
+done by passing the underlying ``fsspec`` implementation. For this purpose
``ObjectStoragePath`` exposes
the ``fs`` property. For example, the following works with ``duckdb`` so that
the connection details from Airflow
are used to connect to s3 and a parquet file, indicated by a
``ObjectStoragePath``, is read:
diff --git a/airflow-core/docs/howto/connection.rst
b/airflow-core/docs/howto/connection.rst
index e58d0260db4..0b9c352c0c4 100644
--- a/airflow-core/docs/howto/connection.rst
+++ b/airflow-core/docs/howto/connection.rst
@@ -113,7 +113,7 @@ If serializing with Airflow URI:
export
AIRFLOW_CONN_MY_PROD_DATABASE='my-conn-type://login:password@host:port/schema?param1=val1¶m2=val2'
-See :ref:`Connection URI format <connection-uri-format>` for more details on
how to generate the a valid URI.
+See :ref:`Connection URI format <connection-uri-format>` for more details on
how to generate a valid URI.
Visibility in UI and CLI
^^^^^^^^^^^^^^^^^^^^^^^^^
diff --git a/airflow-core/docs/installation/upgrading.rst
b/airflow-core/docs/installation/upgrading.rst
index f2be39dd427..990d97ed1fe 100644
--- a/airflow-core/docs/installation/upgrading.rst
+++ b/airflow-core/docs/installation/upgrading.rst
@@ -132,7 +132,7 @@ Get familiar with the internal Database structure of
Airflow which you might fin
Make sure to copy the output. You will need it in the last step. Your
``dag_id``, ``run_id``, ``task_id`` and ``key`` columns should have ``utf8``
or ``utf8mb3`` character
-set set explicitly, similar to:
+set explicitly, similar to:
.. code-block:: text
