This is an automated email from the ASF dual-hosted git repository.
shahar1 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 55d300ecb3e Fix broken code examples and stale references in
airflow-core docs (#73077)
55d300ecb3e is described below
commit 55d300ecb3e3616f015f788d2880f6fd40b22a0e
Author: Andrii Roiko <[email protected]>
AuthorDate: Sun Sep 13 16:33:19 2026 +0300
Fix broken code examples and stale references in airflow-core docs (#73077)
---
.../docs/administration-and-deployment/dagfile-processing.rst | 2 +-
.../logging-monitoring/logging-tasks.rst | 2 +-
.../administration-and-deployment/task-and-asset-state-store.rst | 8 ++++----
airflow-core/docs/authoring-and-scheduling/assets.rst | 2 +-
airflow-core/docs/authoring-and-scheduling/deferring.rst | 9 ++++++---
airflow-core/docs/core-concepts/debug.rst | 2 +-
airflow-core/docs/core-concepts/operators.rst | 4 ++--
airflow-core/docs/core-concepts/params.rst | 4 ++--
airflow-core/docs/core-concepts/task-state-store.rst | 2 +-
airflow-core/docs/howto/customize-ui.rst | 6 +++---
airflow-core/docs/howto/define-extra-link.rst | 4 ++--
airflow-core/docs/howto/sla-to-deadlines.rst | 2 +-
airflow-core/docs/howto/timetable.rst | 2 +-
airflow-core/docs/security/releasing_security_patches.rst | 2 +-
14 files changed, 27 insertions(+), 24 deletions(-)
diff --git
a/airflow-core/docs/administration-and-deployment/dagfile-processing.rst
b/airflow-core/docs/administration-and-deployment/dagfile-processing.rst
index b83c72171a2..2fcb3ca6346 100644
--- a/airflow-core/docs/administration-and-deployment/dagfile-processing.rst
+++ b/airflow-core/docs/administration-and-deployment/dagfile-processing.rst
@@ -24,7 +24,7 @@ Dag File Processing refers to the process of reading the
python files that defin
There are two primary components involved in Dag file processing. The
``DagFileProcessorManager`` is a process executing an infinite loop that
determines which files need
to be processed, and the ``DagFileProcessorProcess`` is a separate process
that is started to convert an individual file into one or more Dag objects.
-The ``DagFileProcessorManager`` runs user codes. As a result, it runs as a
standalone process by running the ``airflow dag-processor`` CLI command.
+The ``DagFileProcessorManager`` coordinates this work but never runs user code
itself; it runs as a standalone process by running the ``airflow
dag-processor`` CLI command.
.. image:: /img/dag_file_processing_diagram.png
diff --git
a/airflow-core/docs/administration-and-deployment/logging-monitoring/logging-tasks.rst
b/airflow-core/docs/administration-and-deployment/logging-monitoring/logging-tasks.rst
index e947fb5c9d8..dc6e4ca9f1a 100644
---
a/airflow-core/docs/administration-and-deployment/logging-monitoring/logging-tasks.rst
+++
b/airflow-core/docs/administration-and-deployment/logging-monitoring/logging-tasks.rst
@@ -176,7 +176,7 @@ Serving logs from workers and triggerer
Most task handlers send logs upon completion of a task. In order to view logs
in real time, Airflow starts an HTTP server to serve the logs in the following
cases:
- If ``LocalExecutor`` is used, then when ``airflow scheduler`` is running.
-- If ``CeleryExecutor`` is used, then when ``airflow worker`` is running.
+- If ``CeleryExecutor`` is used, then when ``airflow celery worker`` is
running.
In triggerer, logs are served unless the service is started with option
``--skip-serve-logs``.
diff --git
a/airflow-core/docs/administration-and-deployment/task-and-asset-state-store.rst
b/airflow-core/docs/administration-and-deployment/task-and-asset-state-store.rst
index 04eb7174fed..e17e8985567 100644
---
a/airflow-core/docs/administration-and-deployment/task-and-asset-state-store.rst
+++
b/airflow-core/docs/administration-and-deployment/task-and-asset-state-store.rst
@@ -83,15 +83,15 @@ Number of rows deleted per batch during garbage collection
cleanup. Set to ``0``
.. _task-and-asset-state-store:worker-backends:
-Worker-side backend (``[workers] state_backend``)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Worker-side backend (``[workers] state_store_backend``)
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A separate, optional config key under ``[workers]`` lets you route task state
store and asset state store values through a worker-side backend before they
reach the API server.
.. code-block:: ini
[workers]
- state_backend = mypackage.state.S3StateBackend
+ state_store_backend = mypackage.state.S3StateBackend
When this is set, ``TaskStateStoreAccessor.set()`` calls
``serialize_task_state_store_to_ref()`` on the worker-side backend before
sending the returned value (a reference to the actual storage) to the Execution
API, and ``get()`` calls ``deserialize_task_state_store_from_ref()`` after
receiving the stored reference from the Execution API. See `Custom worker-side
backends`_ below.
@@ -171,7 +171,7 @@ Configure the class via ``[state_store] backend``:
Custom worker-side backends
----------------------------
-Worker-side backends extend ``BaseStoreBackend`` with two pairs of
serialization hooks. They are configured separately via ``[workers]
state_backend`` and run *on the worker process*, not on the API server. This
lets you store large payloads or credentialed data directly using worker
infrastructure while only a compact reference string is kept in the database.
+Worker-side backends extend ``BaseStoreBackend`` with two pairs of
serialization hooks. They are configured separately via ``[workers]
state_store_backend`` and run *on the worker process*, not on the API server.
This lets you store large payloads or credentialed data directly using worker
infrastructure while only a compact reference string is kept in the database.
Override four serialization hooks from
:class:`~airflow.sdk.state.BaseStoreBackend`:
diff --git a/airflow-core/docs/authoring-and-scheduling/assets.rst
b/airflow-core/docs/authoring-and-scheduling/assets.rst
index bc62e79318c..10d8e341776 100644
--- a/airflow-core/docs/authoring-and-scheduling/assets.rst
+++ b/airflow-core/docs/authoring-and-scheduling/assets.rst
@@ -691,7 +691,7 @@ the downstream Dag will not be triggered for that partition.
The same applies when a mapper cannot transform a key. For example, if an
upstream event has ``partition_key="random-text"`` and the downstream mapping
-uses ``DailyMapper`` (which expects a timestamp-like key), no downstream
+uses ``StartOfDayMapper`` (which expects a timestamp-like key), no downstream
partition match can be produced, so the downstream Dag is not triggered for
that key.
diff --git a/airflow-core/docs/authoring-and-scheduling/deferring.rst
b/airflow-core/docs/authoring-and-scheduling/deferring.rst
index f21a8639d02..3e56c843ce2 100644
--- a/airflow-core/docs/authoring-and-scheduling/deferring.rst
+++ b/airflow-core/docs/authoring-and-scheduling/deferring.rst
@@ -310,7 +310,8 @@ In the sensor part, we'll need to provide the path to
``TimeDeltaTrigger`` as ``
from datetime import timedelta
from typing import Any
- from airflow.sdk import BaseSensorOperator, Context, StartTriggerArgs
+ from airflow.sdk import BaseSensorOperator, Context
+ from airflow.triggers.base import StartTriggerArgs
class WaitOneHourSensor(BaseSensorOperator):
@@ -337,7 +338,8 @@ In the sensor part, we'll need to provide the path to
``TimeDeltaTrigger`` as ``
from datetime import timedelta
from typing import Any
- from airflow.sdk import BaseSensorOperator, Context, StartTriggerArgs
+ from airflow.sdk import BaseSensorOperator, Context
+ from airflow.triggers.base import StartTriggerArgs
class WaitHoursSensor(BaseSensorOperator):
@@ -372,7 +374,8 @@ After the trigger has finished executing, the task may be
sent back to the worke
from datetime import timedelta
from typing import Any
- from airflow.sdk import BaseSensorOperator, Context, StartTriggerArgs
+ from airflow.sdk import BaseSensorOperator, Context
+ from airflow.triggers.base import StartTriggerArgs
class WaitHoursSensor(BaseSensorOperator):
diff --git a/airflow-core/docs/core-concepts/debug.rst
b/airflow-core/docs/core-concepts/debug.rst
index 3ee12bea395..f6b1b7fa2e7 100644
--- a/airflow-core/docs/core-concepts/debug.rst
+++ b/airflow-core/docs/core-concepts/debug.rst
@@ -80,7 +80,7 @@ is manually ingested. The cleanup step is also skipped,
making the intermediate
if __name__ == "__main__":
ingest_testing_data()
run = dag.test(mark_success_pattern="wait_for_.*|cleanup")
- print(f"Intermediate csv:
{run.get_task_instance('collect_stats').xcom_pull(task_id='collect_stats')}")
+ print(f"Intermediate csv:
{run.get_task_instance('collect_stats').xcom_pull(task_ids='collect_stats')}")
Debugging Airflow Dags on the command line
diff --git a/airflow-core/docs/core-concepts/operators.rst
b/airflow-core/docs/core-concepts/operators.rst
index 1a7c0a0015b..ee9606d7595 100644
--- a/airflow-core/docs/core-concepts/operators.rst
+++ b/airflow-core/docs/core-concepts/operators.rst
@@ -213,7 +213,7 @@ In some cases, you may want to exclude a string from
templating and use it direc
)
This will fail with ``TemplateNotFound: cat script.sh`` since Airflow would
treat the string as a path to a file, not a command.
-We can prevent Airflow from treating this value as a reference to a file by
wrapping it in :func:`~airflow.util.template.literal`.
+We can prevent Airflow from treating this value as a reference to a file by
wrapping it in :func:`~airflow.sdk.literal`.
This approach disables the rendering of both macros and files and can be
applied to selected nested fields while retaining the default templating rules
for the remainder of the content.
.. code-block:: python
@@ -226,7 +226,7 @@ This approach disables the rendering of both macros and
files and can be applied
)
.. versionadded:: 2.8
- :func:`~airflow.util.template.literal` was added.
+ :func:`~airflow.sdk.literal` was added.
Alternatively, if you want to prevent Airflow from treating a value as a
reference to a file, you can override ``template_ext``:
diff --git a/airflow-core/docs/core-concepts/params.rst
b/airflow-core/docs/core-concepts/params.rst
index 94c336918a9..47502db86ad 100644
--- a/airflow-core/docs/core-concepts/params.rst
+++ b/airflow-core/docs/core-concepts/params.rst
@@ -117,7 +117,7 @@ Params can be referenced in :ref:`templated strings
<templates-ref>` under ``par
)
Even though Params can use a variety of types, the default behavior of
templates is to provide your task with a string.
-You can change this by setting ``render_template_as_native_obj=True`` while
initializing the :class:`~airflow.models.dag.DAG`.
+You can change this by setting ``render_template_as_native_obj=True`` while
initializing the :class:`~airflow.sdk.DAG`.
.. code-block::
:emphasize-lines: 4
@@ -210,7 +210,7 @@ Use Params to Provide a Trigger UI Form
.. versionadded:: 2.6.0
-:class:`~airflow.models.dag.DAG` level params are used to render a user
friendly trigger form.
+:class:`~airflow.sdk.DAG` level params are used to render a user friendly
trigger form.
This form is provided when a user clicks on the "Trigger Dag" button.
The Trigger UI Form is rendered based on the pre-defined Dag Params. If the
Dag has no params defined, the trigger form is skipped.
diff --git a/airflow-core/docs/core-concepts/task-state-store.rst
b/airflow-core/docs/core-concepts/task-state-store.rst
index c4f7dfa6e40..783a9c0a825 100644
--- a/airflow-core/docs/core-concepts/task-state-store.rst
+++ b/airflow-core/docs/core-concepts/task-state-store.rst
@@ -187,7 +187,7 @@ the default retention window.
On a retry, the task finds the stored ``job_id`` and reattaches instead of
submitting a duplicate job. Another example of this sort of logic can be found
in `example_task_state_store.py
<https://github.com/apache/airflow/blob/main/airflow-core/src/airflow/example_dags/example_task_state_store.py>`_.
-For ``BaseOperator`` subclasses, the
:class:`~airflow.sdk.bases.resumablemixin.ResumableJobMixin` encapsulates this
pattern. It persists the external job ID to task state store after submission
and, on retry, reconnects to an active job or resubmits if the prior job
reached a terminal failure state.
+For ``BaseOperator`` subclasses, the
:class:`~airflow.sdk.bases.resumablejobmixin.ResumableJobMixin` encapsulates
this pattern. It persists the external job ID to task state store after
submission and, on retry, reconnects to an active job or resubmits if the prior
job reached a terminal failure state.
Intra-task checkpointing
~~~~~~~~~~~~~~~~~~~~~~~~
diff --git a/airflow-core/docs/howto/customize-ui.rst
b/airflow-core/docs/howto/customize-ui.rst
index b9d03cdf94d..8c65b70e3fd 100644
--- a/airflow-core/docs/howto/customize-ui.rst
+++ b/airflow-core/docs/howto/customize-ui.rst
@@ -281,7 +281,7 @@ To add static alert messages that remain constant until the
webserver is restart
from airflow.api_fastapi.common.types import UIAlert
DASHBOARD_UIALERTS = [
- UIAlert("Welcome to Airflow", category="info"),
+ UIAlert(text="Welcome to Airflow", category="info"),
]
3. Restart the Airflow webserver, and you should now see the alert message
displayed on the dashboard.
@@ -365,9 +365,9 @@ cases might include alerts yielded from APIs, database
queries or files.
# This method is called each time Airflow iterates over
DASHBOARD_UIALERTS
# Example: Flip a coin
if random.choice([True, False]):
- yield UIAlert("Heads!", category="info")
+ yield UIAlert(text="Heads!", category="info")
else:
- yield UIAlert("Tails!", category="warning")
+ yield UIAlert(text="Tails!", category="warning")
# Create an instance of the class
diff --git a/airflow-core/docs/howto/define-extra-link.rst
b/airflow-core/docs/howto/define-extra-link.rst
index df36f2dded3..39991759300 100644
--- a/airflow-core/docs/howto/define-extra-link.rst
+++ b/airflow-core/docs/howto/define-extra-link.rst
@@ -122,7 +122,7 @@ tasks using
:class:`~airflow.providers.amazon.aws.transfers.gcs_to_s3.GCSToS3Ope
**Overriding Operator Links of Existing Operators**:
It is also possible to replace a built-in link on an operator via a Plugin.
For example
-:class:`~airflow.providers.google.cloud.operators.bigquery.BigQueryExecuteQueryOperator`
includes a link to the Google Cloud
+:class:`~airflow.providers.google.cloud.operators.bigquery.BigQueryInsertJobOperator`
includes a link to the Google Cloud
Console, but if we wanted to change that link we could do:
.. code-block:: python
@@ -130,7 +130,7 @@ Console, but if we wanted to change that link we could do:
from airflow.sdk import BaseOperator, BaseOperatorLink
from airflow.models.taskinstancekey import TaskInstanceKey
from airflow.plugins_manager import AirflowPlugin
- from airflow.providers.google.cloud.operators.bigquery import
BigQueryOperator
+ from airflow.providers.google.cloud.operators.bigquery import
BigQueryInsertJobOperator
# Change from https to http just to display the override
BIGQUERY_JOB_DETAILS_LINK_FMT =
"http://console.cloud.google.com/bigquery?j={job_id}";
diff --git a/airflow-core/docs/howto/sla-to-deadlines.rst
b/airflow-core/docs/howto/sla-to-deadlines.rst
index dd1e4159260..ccfe602360b 100644
--- a/airflow-core/docs/howto/sla-to-deadlines.rst
+++ b/airflow-core/docs/howto/sla-to-deadlines.rst
@@ -75,7 +75,7 @@ Deadline Alerts Example
callback=AsyncCallback(
SlackWebhookNotifier,
kwargs={
- text: "Deadline missed for {{ dag_run.dag_id }}",
+ "text": "Deadline missed for {{ dag_run.dag_id }}",
},
),
),
diff --git a/airflow-core/docs/howto/timetable.rst
b/airflow-core/docs/howto/timetable.rst
index 0fc6fa9ea56..38e28cc0cd3 100644
--- a/airflow-core/docs/howto/timetable.rst
+++ b/airflow-core/docs/howto/timetable.rst
@@ -318,7 +318,7 @@ You can also wrap this inside ``__init__``, if you want to
derive description.
.. code-block:: python
def __init__(self) -> None:
- self.description = "Schedule: after each workday, at
f{self._schedule_at}"
+ self.description = f"Schedule: after each workday, at
{self._schedule_at}"
This is specially useful when you want to provide comprehensive description
which is different from ``summary`` property.
diff --git a/airflow-core/docs/security/releasing_security_patches.rst
b/airflow-core/docs/security/releasing_security_patches.rst
index 07fee71ae70..26fad13e326 100644
--- a/airflow-core/docs/security/releasing_security_patches.rst
+++ b/airflow-core/docs/security/releasing_security_patches.rst
@@ -26,7 +26,7 @@ Releasing Airflow with security patches
---------------------------------------
Apache Airflow uses a strict `SemVer <https://semver.org>`_ versioning policy,
which means that we strive for
-any release of a given ``MAJOR`` Version (version "2" currently) to be
backwards compatible. When we
+any release of a given ``MAJOR`` Version (version "3" currently) to be
backwards compatible. When we
release a ``MINOR`` version, the development continues in the ``main`` branch
where we prepare the next
``MINOR`` version, but we release ``PATCHLEVEL`` releases with selected
bugfixes (including security
bugfixes) cherry-picked to the latest released ``MINOR`` line of Apache
Airflow. At the moment, when we
