This is an automated email from the ASF dual-hosted git repository.
potiuk 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 e386b821844 Fix typos, grammar, and broken references across the docs
(#73146)
e386b821844 is described below
commit e386b821844e736c026d162c9cde26e6b5325305
Author: Andrii Roiko <[email protected]>
AuthorDate: Fri Sep 18 23:31:30 2026 +0300
Fix typos, grammar, and broken references across the docs (#73146)
* Fix typos, grammar, and broken references across the docs
Cleans up a batch of documentation issues found across airflow-core,
task-sdk, airflow-ctl, and chart docs: misspellings and grammar errors,
malformed RST directives and broken cross-references, stale/incorrect
code examples (a wrong module path, a missing import, an off-by-one in
a random.randint example), and a couple of factual inaccuracies (a
stale REST API version reference, an incorrect docker-compose service
name).
Co-Authored-By: Claude Sonnet 5 <[email protected]>
* Revert task-sdk API reference doc dedup
Leaving the autofunction/autoapifunction duplicate entries for task,
setup, and teardown as-is per request.
Co-Authored-By: Claude Sonnet 5 <[email protected]>
---------
Co-authored-by: Claude Sonnet 5 <[email protected]>
---
.../administration-and-deployment/cluster-policies.rst | 4 ++--
.../docs/administration-and-deployment/dag-bundles.rst | 6 +++---
.../administration-and-deployment/dag-serialization.rst | 4 ++--
.../administration-and-deployment/dagfile-processing.rst | 10 +++++-----
.../docs/administration-and-deployment/kubernetes.rst | 4 ++--
.../docs/administration-and-deployment/listeners.rst | 4 ++--
.../logging-monitoring/check-health.rst | 2 +-
.../logging-monitoring/errors.rst | 2 +-
.../administration-and-deployment/modules_management.rst | 2 +-
.../administration-and-deployment/priority-weight.rst | 2 +-
.../production-deployment.rst | 10 +++++-----
.../docs/administration-and-deployment/scheduler.rst | 6 ++++--
.../task-and-asset-state-store.rst | 2 +-
airflow-core/docs/authoring-and-scheduling/assets.rst | 16 ++++++++--------
.../docs/authoring-and-scheduling/connections.rst | 2 +-
airflow-core/docs/authoring-and-scheduling/cron.rst | 2 +-
airflow-core/docs/authoring-and-scheduling/deferring.rst | 2 +-
.../authoring-and-scheduling/dynamic-task-mapping.rst | 8 ++++----
.../docs/authoring-and-scheduling/serializers.rst | 4 ++--
airflow-core/docs/authoring-and-scheduling/timetable.rst | 8 ++++----
airflow-core/docs/best-practices.rst | 6 +++---
airflow-core/docs/core-concepts/backfill.rst | 2 +-
airflow-core/docs/core-concepts/dag-run.rst | 2 +-
airflow-core/docs/core-concepts/dags.rst | 4 ++--
airflow-core/docs/core-concepts/debug.rst | 2 +-
airflow-core/docs/core-concepts/params.rst | 7 +++----
airflow-core/docs/core-concepts/sensors.rst | 2 +-
airflow-core/docs/core-concepts/task-state-store.rst | 2 +-
airflow-core/docs/core-concepts/taskflow.rst | 4 ++--
airflow-core/docs/core-concepts/xcoms.rst | 2 +-
airflow-core/docs/extra-packages-ref.rst | 2 +-
airflow-core/docs/faq.rst | 10 +++++-----
airflow-core/docs/howto/connection.rst | 2 +-
airflow-core/docs/howto/custom-operator.rst | 2 +-
airflow-core/docs/howto/custom-view-plugin.rst | 2 +-
airflow-core/docs/howto/define-extra-link.rst | 2 +-
airflow-core/docs/howto/docker-compose/index.rst | 4 ++--
airflow-core/docs/howto/export-more-env-vars.rst | 2 +-
airflow-core/docs/howto/memory-profiling.rst | 2 +-
airflow-core/docs/howto/run-behind-proxy.rst | 2 +-
airflow-core/docs/howto/set-config.rst | 2 +-
airflow-core/docs/howto/set-up-database.rst | 4 ++--
airflow-core/docs/howto/setup-and-teardown.rst | 4 ++--
airflow-core/docs/howto/sla-to-deadlines.rst | 2 +-
airflow-core/docs/howto/timetable.rst | 6 +++---
airflow-core/docs/installation/dependencies.rst | 14 +++++++-------
airflow-core/docs/installation/index.rst | 4 ++--
.../docs/installation/installing-from-sources.rst | 10 +++++-----
airflow-core/docs/installation/upgrading.rst | 2 +-
airflow-core/docs/installation/upgrading_to_airflow3.rst | 2 +-
airflow-core/docs/public-airflow-interface.rst | 7 +++----
airflow-core/docs/security/audit_logs.rst | 14 +++++++-------
airflow-core/docs/security/kerberos.rst | 4 ++--
airflow-core/docs/security/security_model.rst | 8 ++++----
airflow-core/docs/security/sql.rst | 2 +-
.../vulnerabilities-in-3rd-party-dependencies.rst | 2 +-
airflow-core/docs/start.rst | 2 +-
airflow-core/docs/templates-ref.rst | 10 ++++++----
airflow-core/docs/tutorial/fundamentals.rst | 2 +-
airflow-core/docs/tutorial/hitl.rst | 4 ++--
airflow-core/docs/ui.rst | 4 ++--
airflow-ctl/docs/cli-and-env-variables-ref.rst | 2 +-
airflow-ctl/docs/howto/index.rst | 4 ++--
airflow-ctl/docs/installation/index.rst | 2 +-
.../docs/installation/installing-from-sources.rst | 14 +++++++-------
airflow-ctl/docs/installation/prerequisites.rst | 5 +----
chart/docs/extending-the-chart.rst | 2 +-
chart/docs/manage-dag-files.rst | 2 +-
chart/docs/parameters-ref.rst | 2 +-
chart/docs/production-guide.rst | 12 ++++++------
chart/docs/setting-resources-for-containers.rst | 2 +-
task-sdk/docs/deferred-vs-async-operators.rst | 2 +-
task-sdk/docs/examples.rst | 2 +-
task-sdk/docs/executable-bundle-spec.rst | 1 +
74 files changed, 162 insertions(+), 162 deletions(-)
diff --git
a/airflow-core/docs/administration-and-deployment/cluster-policies.rst
b/airflow-core/docs/administration-and-deployment/cluster-policies.rst
index 7bc1ba5a377..1a09f69916b 100644
--- a/airflow-core/docs/administration-and-deployment/cluster-policies.rst
+++ b/airflow-core/docs/administration-and-deployment/cluster-policies.rst
@@ -66,7 +66,7 @@ cluster policy's value will take precedence.
.. _administration-and-deployment:cluster-policies-define:
-How do define a policy function
+How to define a policy function
-------------------------------
There are two ways to configure cluster policies:
@@ -165,7 +165,7 @@ Here's an example of enforcing a maximum timeout policy on
every task:
:start-after: [START example_task_cluster_policy]
:end-before: [END example_task_cluster_policy]
-You could also implement to protect against common errors, rather than as
technical security controls. For example, don't run tasks without Airflow
owners:
+You could also implement cluster policies to protect against common errors,
rather than as technical security controls. For example, don't run tasks
without Airflow owners:
.. literalinclude:: /../tests/unit/cluster_policies/__init__.py
:language: python
diff --git a/airflow-core/docs/administration-and-deployment/dag-bundles.rst
b/airflow-core/docs/administration-and-deployment/dag-bundles.rst
index 57a91a36c0c..fb0e56bfb62 100644
--- a/airflow-core/docs/administration-and-deployment/dag-bundles.rst
+++ b/airflow-core/docs/administration-and-deployment/dag-bundles.rst
@@ -18,7 +18,7 @@
Dag Bundles
===========
-A Dag bundle is a collection of one or more Dags, files along with their
associated files, such as other
+A Dag bundle is a collection of one or more Dag files along with their
associated files, such as other
Python scripts, configuration files, or other resources. Dag bundles can
source the Dags from various
locations, such as local directories, Git repositories, or other external
systems. Deployment administrators
can also write their own Dag bundle classes to support custom sources. You can
also define more than one Dag
@@ -217,7 +217,7 @@ The url is verified for safety, and if it is not safe, the
view url for the bund
You can also override the :ref:`config:dag_processor__refresh_interval` per
Dag bundle by passing it in kwargs.
This controls how often the Dag processor refreshes, or looks for new files,
in the Dag bundles.
-Starting Airflow 3.0.2 git is pre installed in the base image. However, if you
are using versions prior 3.0.2, you would need to install git in your docker
image.
+Starting with Airflow 3.0.2, git is pre-installed in the base image. However,
if you are using versions prior to 3.0.2, you would need to install git in your
docker image.
.. code-block:: Dockerfile
@@ -446,7 +446,7 @@ Other Considerations
- **Versioning**: If your bundle supports versioning, ensure that
``initialize``, ``get_current_version`` and ``refresh`` are implemented to
handle version-specific logic.
-- **Concurrency**: Workers may create many bundles simultaneously, and does
nothing to serialize calls to the bundle objects. Thus, the bundle class must
handle locking if
+- **Concurrency**: Workers may create many bundles simultaneously, and Airflow
does nothing to serialize calls to the bundle objects. Thus, the bundle class
must handle locking if
that is problematic for the underlying technology. For example, if you are
cloning a git repo, the bundle class is responsible for locking to ensure only
1 bundle
object is cloning at a time. There is a ``lock`` method in the base class
that can be used for this purpose, if necessary.
diff --git
a/airflow-core/docs/administration-and-deployment/dag-serialization.rst
b/airflow-core/docs/administration-and-deployment/dag-serialization.rst
index 6ad5b47864f..75bcb2ba379 100644
--- a/airflow-core/docs/administration-and-deployment/dag-serialization.rst
+++ b/airflow-core/docs/administration-and-deployment/dag-serialization.rst
@@ -53,8 +53,8 @@ You can enable the source code to be stored in the database
to make the Webserve
This is not necessary if your files are embedded in the Docker image or you
can otherwise provide
them to the Webserver. The data is stored in the
:class:`~airflow.models.dagcode.DagCode` model.
-The last element is rendering template fields. When serialization is enabled,
templates are not rendered
-to requests, but a copy of the field contents is saved before the task is
executed on worker.
+The last element is rendering template fields. When serialization is enabled,
templates are not re-rendered
+on request, but a copy of the field contents is saved before the task is
executed on worker.
The data is stored in the
:class:`~airflow.models.renderedtifields.RenderedTaskInstanceFields` model.
To limit the excessive growth of the database, only the most recent entries
are kept and older entries
are purged.
diff --git
a/airflow-core/docs/administration-and-deployment/dagfile-processing.rst
b/airflow-core/docs/administration-and-deployment/dagfile-processing.rst
index 2fcb3ca6346..5fead75ef95 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`` coordinates this work but never runs user code
itself; 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 is started as a standalone process via the ``airflow dag-processor``
CLI command.
.. image:: /img/dag_file_processing_diagram.png
@@ -51,7 +51,7 @@ Fine-tuning your Dag processor performance
What impacts Dag processor's performance
""""""""""""""""""""""""""""""""""""""""
-The Dag processor is responsible for continuously parsing Dag files and
synchronizing with the Dag in the database
+The Dag processor is responsible for continuously parsing Dag files and
synchronizing with the Dag in the database.
In order to fine-tune your Dag processor, you need to include a number of
factors:
* The kind of deployment you have
@@ -103,8 +103,8 @@ to observe and monitor your systems):
* based on your expectations and observations - decide what is your next
improvement and go back to
the observation of your performance, bottlenecks. Performance improvement is
an iterative process.
-What resources might limit Dag processors's performance
-"""""""""""""""""""""""""""""""""""""""""""""""""""""""
+What resources might limit Dag processor's performance
+""""""""""""""""""""""""""""""""""""""""""""""""""""""
There are several areas of resource usage that you should pay attention to:
@@ -134,7 +134,7 @@ There are several areas of resource usage that you should
pay attention to:
`PGBouncer <https://www.pgbouncer.org/>`_ as a proxy to your database. The
:doc:`helm-chart:index`
supports PGBouncer out-of-the-box.
* CPU usage is most important for FileProcessors - those are the processes
that parse and execute
- Python Dag files. Since Dag processors typically triggers such parsing
continuously, when you have a lot of Dags,
+ Python Dag files. Since Dag processors typically trigger such parsing
continuously, when you have a lot of Dags,
the processing might take a lot of CPU. You can mitigate it by increasing the
:ref:`config:dag_processor__min_file_process_interval`, but this is one of
the mentioned trade-offs,
result of this is that changes to such files will be picked up slower and
you will see delays between
diff --git a/airflow-core/docs/administration-and-deployment/kubernetes.rst
b/airflow-core/docs/administration-and-deployment/kubernetes.rst
index 3a4be87280d..de5ec5e2207 100644
--- a/airflow-core/docs/administration-and-deployment/kubernetes.rst
+++ b/airflow-core/docs/administration-and-deployment/kubernetes.rst
@@ -48,8 +48,8 @@ Pod Mutation Hook
The Airflow local settings file (``airflow_local_settings.py``) can define a
``pod_mutation_hook`` function
that has the ability to mutate pod objects before sending them to the
Kubernetes client
-for scheduling. It receives a single argument as a reference to pod objects,
and
-are expected to alter its attributes.
+for scheduling. It receives a single argument as a reference to the pod
object, and
+is expected to alter its attributes.
This could be used, for instance, to add sidecar or init containers
to every worker pod launched by KubernetesExecutor or KubernetesPodOperator.
diff --git a/airflow-core/docs/administration-and-deployment/listeners.rst
b/airflow-core/docs/administration-and-deployment/listeners.rst
index 70dde0b7fd2..cf653f2fbe5 100644
--- a/airflow-core/docs/administration-and-deployment/listeners.rst
+++ b/airflow-core/docs/administration-and-deployment/listeners.rst
@@ -34,7 +34,7 @@ Lifecycle Events
- ``on_starting``
- ``before_stopping``
-Lifecycle events allow you to react to start and stop events for an Airflow
``Job``, like ``SchedulerJob``.
+Lifecycle events allow you to react to start and stop events for an Airflow
``Job``, like ``SchedulerJob``.
DagRun State Change Events
--------------------------
@@ -119,7 +119,7 @@ Dag Import Error Events
- ``on_new_dag_import_error``
- ``on_existing_dag_import_error``
-Dag import error events occur when Dag processor finds import error in the Dag
code and update the metadata database table.
+Dag import error events occur when Dag processor finds an import error in the
Dag code and updates the metadata database table.
|experimental|
diff --git
a/airflow-core/docs/administration-and-deployment/logging-monitoring/check-health.rst
b/airflow-core/docs/administration-and-deployment/logging-monitoring/check-health.rst
index 5289e7f042c..878f9496867 100644
---
a/airflow-core/docs/administration-and-deployment/logging-monitoring/check-health.rst
+++
b/airflow-core/docs/administration-and-deployment/logging-monitoring/check-health.rst
@@ -24,7 +24,7 @@ Airflow has two methods to check the health of components -
HTTP checks and CLI
accessible through the CLI, but only some are accessible through HTTP due to
the role of the component being checked
and the tools being used to monitor the deployment.
-For example, when running on Kubernetes, use `a Liveness probes
<https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/>`__
(``livenessProbe`` property)
+For example, when running on Kubernetes, use `a Liveness probe
<https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/>`__
(``livenessProbe`` property)
with :ref:`CLI checks <check-health/cli-checks-for-scheduler>` on the
scheduler deployment to restart it when it fails.
For the webserver, you can configure the readiness probe (``readinessProbe``
property) using :ref:`check-health/http-endpoint`.
diff --git
a/airflow-core/docs/administration-and-deployment/logging-monitoring/errors.rst
b/airflow-core/docs/administration-and-deployment/logging-monitoring/errors.rst
index f2f04405382..bee43b756ba 100644
---
a/airflow-core/docs/administration-and-deployment/logging-monitoring/errors.rst
+++
b/airflow-core/docs/administration-and-deployment/logging-monitoring/errors.rst
@@ -79,7 +79,7 @@ in favor of ``data_interval_start``.
Breadcrumbs
------------
-When a task fails with an error `breadcrumbs
<https://docs.sentry.io/platforms/python/enriching-events/breadcrumbs/>`__ will
be added for the other tasks in the current Dag run.
+When a task fails with an error, `breadcrumbs
<https://docs.sentry.io/platforms/python/enriching-events/breadcrumbs/>`__ will
be added for the other tasks in the current Dag run.
=======================================
==============================================================
Name Description
diff --git
a/airflow-core/docs/administration-and-deployment/modules_management.rst
b/airflow-core/docs/administration-and-deployment/modules_management.rst
index 69c40932940..f5125d05ffe 100644
--- a/airflow-core/docs/administration-and-deployment/modules_management.rst
+++ b/airflow-core/docs/administration-and-deployment/modules_management.rst
@@ -118,7 +118,7 @@ In the case above, these are the ways you could import the
python files:
You can see the ``.airflowignore`` file at the root of your folder. This is a
file that you can put in your
``dags`` folder to tell Airflow which files from the folder should be ignored
when the Airflow
-scheduler looks for Dags. It should contain either regular expressions (the
default) or glob expressions
+scheduler looks for Dags. It should contain either glob expressions (the
default) or regular expressions
for the paths that should be ignored. You do not need to have that file in any
other folder in
``PYTHONPATH`` (and also you can only keep shared code in the other folders,
not the actual Dags).
diff --git
a/airflow-core/docs/administration-and-deployment/priority-weight.rst
b/airflow-core/docs/administration-and-deployment/priority-weight.rst
index 3e8ed11cd4c..90e4c0b5c32 100644
--- a/airflow-core/docs/administration-and-deployment/priority-weight.rst
+++ b/airflow-core/docs/administration-and-deployment/priority-weight.rst
@@ -58,7 +58,7 @@ Below are the weighting methods. By default, Airflow's
weighting method is ``dow
without additional weighting. You may want to do this when you
know exactly what priority weight each task should have.
Additionally, when set to ``absolute``, there is bonus effect of
- significantly speeding up the task creation process as for very
+ significantly speeding up the task creation process, especially for very
large Dags.
diff --git
a/airflow-core/docs/administration-and-deployment/production-deployment.rst
b/airflow-core/docs/administration-and-deployment/production-deployment.rst
index 8e1258bb9da..56fe3ed3cc5 100644
--- a/airflow-core/docs/administration-and-deployment/production-deployment.rst
+++ b/airflow-core/docs/administration-and-deployment/production-deployment.rst
@@ -157,7 +157,7 @@ Make sure to test such live upgrade procedure in a staging
environment before yo
to avoid any surprises and side-effects.
When it comes to live-upgrading the ``Webserver``, ``Triggerer`` components,
if you run them in separate
-environments and have more than one instances for each of them, you can
rolling-restart them one by one,
+environments and have more than one instance for each of them, you can
rolling-restart them one by one,
without any downtime. This should usually be done as the first step in your
upgrade procedure.
When you are running a deployment with separate ``Dag processor``, in a
@@ -182,7 +182,7 @@ of the executor you use:
of running tasks going down to zero. Once the workers are upgraded, they
will be automatically put in online
mode and start picking up new tasks. You can then upgrade the ``Scheduler``
in a rolling restart mode.
-* For the :doc:`Kubernetes executor
<apache-airflow-providers-cncf-kubernetes:kubernetes_executor>`, you can
upgrade the scheduler
+* For the :doc:`Kubernetes executor
<apache-airflow-providers-cncf-kubernetes:kubernetes_executor>`, you can
upgrade the scheduler,
triggerer, webserver in a rolling restart mode, and generally you should not
worry about the workers, as they
are managed by the Kubernetes cluster and will be automatically adopted by
``Schedulers`` when they are
upgraded and restarted.
@@ -254,8 +254,8 @@ Impersonate Service Accounts
----------------------------
If you need access to other service accounts, you can
-:ref:`impersonate other service accounts
<howto/connection:google_cloud_platform:impersonation>` to exchange the token
with
-the default identity to another service account. Thus, the account keys are
still managed by Google
+:ref:`impersonate other service accounts
<howto/connection:google_cloud_platform:impersonation>` to exchange the token of
+the default identity for that of another service account. Thus, the account
keys are still managed by Google
and cannot be read by your workload.
It is not recommended to generate service account keys and store them in the
metadata database or the
@@ -270,7 +270,7 @@ of this instance and credentials to access it. To simplify
this task, you can us
:class:`~airflow.providers.google.cloud.hooks.compute.ComputeEngineHook`
instead of :class:`~airflow.providers.ssh.hooks.ssh.SSHHook`
-The :class:`~airflow.providers.google.cloud.hooks.compute.ComputeEngineHook`
support authorization with
+The :class:`~airflow.providers.google.cloud.hooks.compute.ComputeEngineHook`
supports authorization with
Google OS Login service. It is an extremely robust way to manage Linux access
properly as it stores
short-lived ssh keys in the metadata service, offers PAM modules for access
and sudo privilege checking
and offers the ``nsswitch`` user lookup into the metadata service as well.
diff --git a/airflow-core/docs/administration-and-deployment/scheduler.rst
b/airflow-core/docs/administration-and-deployment/scheduler.rst
index 2bb447c0774..db329bfe5cc 100644
--- a/airflow-core/docs/administration-and-deployment/scheduler.rst
+++ b/airflow-core/docs/administration-and-deployment/scheduler.rst
@@ -61,7 +61,7 @@ In the UI, it appears as if Airflow is running your tasks a
day **late**
.. note::
The scheduler is designed for high throughput. This is an informed design
decision to achieve scheduling
- tasks as soon as possible. The scheduler checks how many free slots
available in a pool and schedule at most that number of tasks instances in one
iteration.
+ tasks as soon as possible. The scheduler checks how many free slots are
available in a pool and schedules at most that number of task instances in one
iteration.
This means that task priority will only come into effect when there are
more scheduled tasks
waiting than the queue slots. Thus there can be cases where low priority
tasks will be scheduled before high priority tasks if they share the same batch.
For more read about that you can reference `this GitHub discussion
<https://github.com/apache/airflow/discussions/28809>`__.
@@ -71,7 +71,7 @@ In the UI, it appears as if Airflow is running your tasks a
day **late**
Running More Than One Scheduler
-------------------------------
-.. versionadded: 2.0.0
+.. versionadded:: 2.0.0
Airflow supports running more than one scheduler concurrently -- both for
performance reasons and for
resiliency.
@@ -283,6 +283,7 @@ However, you can also look at other non-performance-related
scheduler configurat
monitored by this scheduler instead.
- :ref:`config:scheduler__max_tis_per_query`
+
The batch size of queries in the scheduling main loop. This should not be
greater than
``core.parallelism``. If this is too high then SQL query performance may be
impacted by
complexity of query predicate, and/or excessive locking.
@@ -291,6 +292,7 @@ However, you can also look at other non-performance-related
scheduler configurat
Set this to 0 to use the value of ``core.parallelism``.
- :ref:`config:scheduler__scheduler_idle_sleep_time`
+
Controls how long the scheduler will sleep between loops, but if there was
nothing to do
in the loop. i.e. if it scheduled something then it will start the next loop
iteration straight away. This parameter is badly named (historical reasons)
and it will be
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 e17e8985567..706d5576679 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
@@ -105,7 +105,7 @@ The cleanup task, also known as "garbage collection" is
triggered using the Airf
Rows whose ``expires_at < now()`` are deleted. ``expires_at`` is computed on
the *worker* at write time, not by the server.
**``default_retention_days`` fallback (task state store only)**
- Keys written with no explicit retention get an ``expires_at`` of now +
default_retention_days computed at write time. Garbage collection deletes rows
where ``expires_at < now()``."
+ Keys written with no explicit retention get an ``expires_at`` of now +
default_retention_days computed at write time. Garbage collection deletes rows
where ``expires_at < now()``.
**``NEVER_EXPIRE`` keys**
Keys set with ``retention=NEVER_EXPIRE`` are stored with ``expires_at =
NULL`` and a flag that tells the garbage collection to skip them
unconditionally. They are never deleted by time-based cleanup, regardless of
``default_retention_days``.
diff --git a/airflow-core/docs/authoring-and-scheduling/assets.rst
b/airflow-core/docs/authoring-and-scheduling/assets.rst
index 10d8e341776..45d1a5753a5 100644
--- a/airflow-core/docs/authoring-and-scheduling/assets.rst
+++ b/airflow-core/docs/authoring-and-scheduling/assets.rst
@@ -31,7 +31,7 @@ What is an "Asset"?
An Airflow asset is a logical grouping of data. Upstream producer tasks can
update assets, and asset updates contribute to scheduling downstream consumer
Dags.
-`Uniform Resource Identifier (URI)
<https://en.wikipedia.org/wiki/Uniform_Resource_Identifier>`_ define assets:
+`Uniform Resource Identifiers (URI)
<https://en.wikipedia.org/wiki/Uniform_Resource_Identifier>`_ define assets:
.. code-block:: python
@@ -56,7 +56,7 @@ Technically, the URI must conform to the valid character set
in RFC 3986, which
The URI is also case sensitive, so ``s3://example/asset`` and
``s3://Example/asset`` are considered different. Note that the *host* part of
the URI is also case sensitive, which differs from RFC 3986.
-For pre-defined schemes (e.g., ``file``, ``postgres``, and ``s3``), you must
provide a meaning URI. If you can't provide one, use another scheme altogether
that don't have the semantic restrictions. Airflow will never require a
semantic for user-defined URI schemes (with a prefix x-), so that can be a
good alternative. If you have a URI that can only be obtained later (e.g.,
during task execution), consider using ``AssetAlias`` instead and update the
URI later.
+For pre-defined schemes (e.g., ``file``, ``postgres``, and ``s3``), you must
provide a meaningful URI. If you can't provide one, use another scheme
altogether that doesn't have the semantic restrictions. Airflow will never
require a semantic for user-defined URI schemes (with a prefix x-), so that
can be a good alternative. If you have a URI that can only be obtained later
(e.g., during task execution), consider using ``AssetAlias`` instead and update
the URI later.
.. code-block:: python
@@ -65,7 +65,7 @@ For pre-defined schemes (e.g., ``file``, ``postgres``, and
``s3``), you must pro
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.
+Airflow always prefers using lowercase in schemes, and case sensitivity is
needed in the host part of the URI to correctly distinguish between resources.
.. code-block:: python
@@ -103,9 +103,9 @@ If needed, you can include an additional dictionary in an
asset using the ``extr
)
This allows you to provide custom metadata about the asset, such as ownership
information or the purpose of the file. The ``extra`` field does **NOT** affect
the identity of an asset.
-Thus, maintaining the uniqueness of the ``extra`` value is the user
responsibility. It suggested to have only one single set of ``extra`` value per
asset.
+Thus, maintaining the uniqueness of the ``extra`` value is the user's
responsibility. It is suggested to have only one single set of ``extra`` value
per asset.
-For example, in the following snippet, only one of the ``extra`` dictionaries
will ultimately be stored, but it does guaranteed which one will be stored.
+For example, in the following snippet, only one of the ``extra`` dictionaries
will ultimately be stored, but it is not guaranteed which one will be stored.
.. code-block:: python
@@ -234,7 +234,7 @@ Fetching information from previously emitted asset events
.. versionadded:: 2.10.0
-Events of an asset defined in a task's ``outlets``, as described in the
previous section, can be read by a task that declares the same asset in its
``inlets``. A asset event entry contains ``extra`` (see previous section for
details), ``timestamp`` indicating when the event was emitted from a task, and
``source_task_instance`` linking the event back to its source.
+Events of an asset defined in a task's ``outlets``, as described in the
previous section, can be read by a task that declares the same asset in its
``inlets``. An asset event entry contains ``extra`` (see previous section for
details), ``timestamp`` indicating when the event was emitted from a task, and
``source_task_instance`` linking the event back to its source.
Inlet asset events can be read with the ``inlet_events`` accessor in the
execution context. Continuing from the ``write_to_s3`` asset in the previous
section:
@@ -282,7 +282,7 @@ Each ``extra`` value uses ``key=value`` format. Multiple
entries are combined wi
Dependency between ``@asset``, ``@task``, and classic operators
---------------------------------------------------------------
-Since an ``@asset`` is simply a wrapper around a Dag with a task and an asset,
it is quite easy to read and ``@asset`` in a ``@task`` or a classic operator.
For example, the above ``post_process_s3_file`` can also be written as a task
(inside a Dag, omitted here for brevity):
+Since an ``@asset`` is simply a wrapper around a Dag with a task and an asset,
it is quite easy to read from an ``@asset`` in a ``@task`` or a classic
operator. For example, the above ``post_process_s3_file`` can also be written
as a task (inside a Dag, omitted here for brevity):
.. code-block:: python
@@ -538,7 +538,7 @@ Asset partitions
.. versionadded:: 3.2.0
-Asset events can include a ``partition_key`` to make it _partitioned__. This
lets you model
+Asset events can include a ``partition_key`` to make it *partitioned*. This
lets you model
the same asset at partition granularity (for example, ``2026-03-10T09:00:00``
for an
hourly partition).
diff --git a/airflow-core/docs/authoring-and-scheduling/connections.rst
b/airflow-core/docs/authoring-and-scheduling/connections.rst
index 7f9cbaa443e..1df51ee8806 100644
--- a/airflow-core/docs/authoring-and-scheduling/connections.rst
+++ b/airflow-core/docs/authoring-and-scheduling/connections.rst
@@ -43,7 +43,7 @@ You can view a :ref:`full list of Airflow hooks
<pythonapi:hooks>` in our API do
Custom connections
------------------
-Airflow allows to define custom connection types. This is what is described in
detail in
+Airflow allows you to define custom connection types. This is what is
described in detail in
:doc:`apache-airflow-providers:index` - providers give you the capability of
defining your own connections.
The connection customization can be done by any provider, but also
many of the providers managed by the community define custom connection types.
diff --git a/airflow-core/docs/authoring-and-scheduling/cron.rst
b/airflow-core/docs/authoring-and-scheduling/cron.rst
index 5683daeedf9..b5d1e65ce27 100644
--- a/airflow-core/docs/authoring-and-scheduling/cron.rst
+++ b/airflow-core/docs/authoring-and-scheduling/cron.rst
@@ -53,7 +53,7 @@ For example, you can create a Dag schedule to run at 12AM on
the first Monday of
+----------------+--------------------------------------------------------------------+-----------------+
| ``@continuous``| Run as soon as the previous run finishes
| |
+----------------+--------------------------------------------------------------------+-----------------+
-| ``@hourly`` | Run once an hour at the end of the hour
| ``0 * * * *`` |
+| ``@hourly`` | Run once an hour at the beginning of the hour
| ``0 * * * *`` |
+----------------+--------------------------------------------------------------------+-----------------+
| ``@daily`` | Run once a day at midnight (24:00)
| ``0 0 * * *`` |
+----------------+--------------------------------------------------------------------+-----------------+
diff --git a/airflow-core/docs/authoring-and-scheduling/deferring.rst
b/airflow-core/docs/authoring-and-scheduling/deferring.rst
index 3e56c843ce2..f767cde9867 100644
--- a/airflow-core/docs/authoring-and-scheduling/deferring.rst
+++ b/airflow-core/docs/authoring-and-scheduling/deferring.rst
@@ -589,7 +589,7 @@ queue values are set to either ``"team_A"`` or
``"team_B"``):
Difference between Mode='reschedule' and Deferrable=True in Sensors
-------------------------------------------------------------------
-In Airflow, sensors wait for specific conditions to be met before proceeding
with downstream tasks. Sensors have two options for managing idle periods:
``mode='reschedule'`` and ``deferrable=True``. Because ``mode='reschedule'`` is
a parameter specific to the BaseSensorOperator in Airflow, it allows the sensor
to reschedule itself if the condition is not met. ``'deferrable=True'`` is a
convention used by some operators to indicate that the task can be retried (or
deferred) later, but it [...]
+In Airflow, sensors wait for specific conditions to be met before proceeding
with downstream tasks. Sensors have two options for managing idle periods:
``mode='reschedule'`` and ``deferrable=True``. Because ``mode='reschedule'`` is
a parameter specific to the BaseSensorOperator in Airflow, it allows the sensor
to reschedule itself if the condition is not met. ``deferrable=True`` is a
parameter supported by individual deferrable operators and sensors to indicate
that the task should suspe [...]
+--------------------------------------------------------+--------------------------------------------------------+
| mode='reschedule' |
deferrable=True |
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 d3a3f9cfa1d..3e2a9e09e80 100644
--- a/airflow-core/docs/authoring-and-scheduling/dynamic-task-mapping.rst
+++ b/airflow-core/docs/authoring-and-scheduling/dynamic-task-mapping.rst
@@ -364,7 +364,7 @@ In the above example, task ``convert_to_yaml`` is expanded
into two task instanc
Value references in a task group function
-----------------------------------------
-One important distinction between a task function (``@task``) and a task
*group* function (``@task_group``) is, since a task group does not have an
associated worker, code in a task group function cannot resolve arguments
passed into it; the real value and is only resolved when the reference is
passed into a task.
+One important distinction between a task function (``@task``) and a task
*group* function (``@task_group``) is, since a task group does not have an
associated worker, code in a task group function cannot resolve arguments
passed into it; the real value is only resolved when the reference is passed
into a task.
For example, this code will *not* work:
@@ -388,7 +388,7 @@ For example, this code will *not* work:
When code in ``my_task_group`` is executed, ``value`` would still only be a
reference, not the real value, so the ``if not value`` branch will not work as
you likely want. However, if you pass that reference into a task, it will
become resolved when the task is executed, and the three ``my_task`` instances
will therefore receive 1, 2, and 3, respectively.
-It is, therefore, important to remember that, if you intend to perform any
logic to a value passed into a task group function, you must always use a task
to run the logic, such as ``@task.branch`` (or ``BranchPythonOperator``) for
conditions, and task mapping methods for loops.
+It is, therefore, important to remember that, if you intend to perform any
logic on a value passed into a task group function, you must always use a task
to run the logic, such as ``@task.branch`` (or ``BranchPythonOperator``) for
conditions, and task mapping methods for loops.
.. note:: Task-mapping in a mapped task group is not permitted
@@ -648,8 +648,8 @@ Placing limits on mapped tasks
There are two limits that you can place on a task:
- #. the number of mapped task instances can be created as the result of
expansion.
- #. The number of the mapped task can run at once.
+ #. the number of mapped task instances that can be created as the result of
expansion.
+ #. The number of the mapped task instances that can run at once.
- **Limiting number of mapped task**
diff --git a/airflow-core/docs/authoring-and-scheduling/serializers.rst
b/airflow-core/docs/authoring-and-scheduling/serializers.rst
index 400b394267e..1fadde9a932 100644
--- a/airflow-core/docs/authoring-and-scheduling/serializers.rst
+++ b/airflow-core/docs/authoring-and-scheduling/serializers.rst
@@ -46,7 +46,7 @@ Airflow resolves custom serialization in the following order:
If you are looking to extend Airflow with a new serializer, it is good to know
when to choose what way of serialization.
Objects that are under the control of Airflow, i.e. residing under the
namespace of ``airflow.*`` like
-``airflow.model.dag.DAG`` or under control of the developer e.g.
``my.company.Foo`` should first be examined to see
+``airflow.models.dag.DAG`` or under control of the developer e.g.
``my.company.Foo`` should first be examined to see
whether they can be decorated with ``@attr.define`` or ``@dataclass``. If that
is not possible then the ``serialize``
and ``deserialize`` methods should be implemented. The ``serialize`` method
should return a primitive or a dict.
It does not need to serialize the values in the dict, that will be taken care
of, but the keys should be of a primitive
@@ -85,7 +85,7 @@ Airflow Object
@staticmethod
def deserialize(data: dict[str, Any], version: int):
- f = Foo(a=data["a"], v=data["b"])
+ f = Foo(a=data["a"], v=data["b"]["x"])
return f
diff --git a/airflow-core/docs/authoring-and-scheduling/timetable.rst
b/airflow-core/docs/authoring-and-scheduling/timetable.rst
index 525b975db16..2deefe9429c 100644
--- a/airflow-core/docs/authoring-and-scheduling/timetable.rst
+++ b/airflow-core/docs/authoring-and-scheduling/timetable.rst
@@ -29,7 +29,7 @@ internally converted to always use a timetable.
If a cron expression or ``timedelta`` is sufficient for your use case, you
don't need
to worry about writing a custom timetable because Airflow has default
timetables that handle those cases.
But for more complicated scheduling requirements,
-you can create your own timetable class and pass that to the Dags ``schedule``
argument.
+you can create your own timetable class and pass that to the Dag's
``schedule`` argument.
Some examples of when custom timetable implementations are useful:
@@ -48,7 +48,7 @@ Some examples of when custom timetable implementations are
useful:
.. _`Traditional Chinese Calendar`:
https://en.wikipedia.org/wiki/Chinese_calendar
-Airflow allows you to write custom timetables in plugins and used by
+Airflow allows you to write custom timetables in plugins and use them in
Dags. You can find an example demonstrating a custom timetable in the
:doc:`/howto/timetable` how-to guide.
@@ -409,7 +409,7 @@ data interval that they cover, depending on 3 arguments:
``schedule``, ``start_d
- ``True``
- * 00:00 - 00:30
* 00:30 - 01:00
- - Same behavior than using the timedelta object.
+ - Same behavior as using the timedelta object.
* - ``*/30 * * * *``
- ``year-02-01``
@@ -434,7 +434,7 @@ data interval that they cover, depending on 3 arguments:
``schedule``, ``start_d
- ``True``
- * 00:00 - 00:30
* 00:30 - 01:00
- - Same behavior than using the cron expression.
+ - Same behavior as using the cron expression.
* - ``datetime.timedelta(minutes=30)``
- ``year-02-01``
diff --git a/airflow-core/docs/best-practices.rst
b/airflow-core/docs/best-practices.rst
index 881564be186..a7b34a9fa51 100644
--- a/airflow-core/docs/best-practices.rst
+++ b/airflow-core/docs/best-practices.rst
@@ -1048,7 +1048,7 @@ Using ExternalPythonOperator
.. versionadded:: 2.4
A bit more involved but with significantly less overhead, security, stability
problems is to use the
-:class:`airflow.providers.standard.operators.python.ExternalPythonOperator``.
In the modern
+:class:`airflow.providers.standard.operators.python.ExternalPythonOperator`.
In the modern
TaskFlow approach described in :doc:`/tutorial/taskflow`. this also can be
done with decorating
your callable with ``@task.external_python`` decorator (recommended way of
using the operator).
It requires, however, that you have a pre-existing, immutable Python
environment, that is prepared upfront.
@@ -1131,7 +1131,7 @@ As of version 2.2 of Airflow you can use ``@task.docker``
decorator to run your
.. versionadded:: 2.4
-As of version 2.2 of Airflow you can use ``@task.kubernetes`` decorator to run
your functions with ``KubernetesPodOperator``.
+As of version 2.4 of Airflow you can use ``@task.kubernetes`` decorator to run
your functions with ``KubernetesPodOperator``.
The benefits of using those operators are:
@@ -1172,7 +1172,7 @@ The drawbacks:
provided by those two are "leaky", so you need to understand a bit more
about resources, networking,
containers etc. in order to author a Dag that uses those operators.
-You can see detailed examples of using
:class:`airflow.operators.providers.Docker` in
+You can see detailed examples of using
:class:`airflow.providers.docker.operators.docker.DockerOperator` in
:ref:`TaskFlow Docker example <taskflow-docker_environment>`
and
:class:`airflow.providers.cncf.kubernetes.operators.pod.KubernetesPodOperator`
:ref:`TaskFlow Kubernetes example <tasfklow-kpo>`
diff --git a/airflow-core/docs/core-concepts/backfill.rst
b/airflow-core/docs/core-concepts/backfill.rst
index e8ecf675e1a..d28a1d60dbf 100644
--- a/airflow-core/docs/core-concepts/backfill.rst
+++ b/airflow-core/docs/core-concepts/backfill.rst
@@ -39,7 +39,7 @@ Concurrency control
-------------------
You can set ``max_active_runs`` on a backfill and it will control how many Dag
runs in
-the backfill can run concurrently. Backfill ``max_active_runs`` is applied
independently
+the backfill can run concurrently. Backfill ``max_active_runs`` is applied
independently of
the Dag ``max_active_runs`` setting.
Once a backfill's Dag runs are actually running, the scheduler does not
otherwise
diff --git a/airflow-core/docs/core-concepts/dag-run.rst
b/airflow-core/docs/core-concepts/dag-run.rst
index f72dd8d6ac0..dad6eb51147 100644
--- a/airflow-core/docs/core-concepts/dag-run.rst
+++ b/airflow-core/docs/core-concepts/dag-run.rst
@@ -28,7 +28,7 @@ Dag Run Status
A Dag Run status is determined when the execution of the Dag is finished.
The execution of the Dag depends on its containing tasks and their
dependencies.
-The status is assigned to the Dag Run when all of the tasks are in the one of
the terminal states (i.e. if there is no possible transition to another state)
like ``success``, ``failed`` or ``skipped``.
+The status is assigned to the Dag Run when all of the tasks are in one of the
terminal states (i.e. if there is no possible transition to another state) like
``success``, ``failed`` or ``skipped``.
The Dag Run is having the status assigned based on the so-called "leaf nodes"
or simply "leaves". Leaf nodes are the tasks with no children.
There are two possible terminal states for the Dag Run:
diff --git a/airflow-core/docs/core-concepts/dags.rst
b/airflow-core/docs/core-concepts/dags.rst
index b08c1dc5538..18acf9bbdec 100644
--- a/airflow-core/docs/core-concepts/dags.rst
+++ b/airflow-core/docs/core-concepts/dags.rst
@@ -699,7 +699,7 @@ This is especially useful if your tasks are built
dynamically from configuration
t = EmptyOperator(task_id="foo")
t.doc_md = """\
- #Title"
+ # Title
Here's a [url](www.airbnb.com)
"""
@@ -865,7 +865,7 @@ Here's a simple example using the existing email Notifier:
.. code-block:: python
from datetime import timedelta
- from airflow import DAG
+ from airflow.sdk import DAG
from airflow.providers.smtp.notifications.smtp import SmtpNotifier
from airflow.sdk.definitions.deadline import DeadlineAlert,
DeadlineReference
diff --git a/airflow-core/docs/core-concepts/debug.rst
b/airflow-core/docs/core-concepts/debug.rst
index f6b1b7fa2e7..4d298a00e21 100644
--- a/airflow-core/docs/core-concepts/debug.rst
+++ b/airflow-core/docs/core-concepts/debug.rst
@@ -52,7 +52,7 @@ To set up ``dag.test``, add these two lines to the bottom of
your Dag file:
and that's it! You can add optional arguments to fine tune the testing but
otherwise you can run or debug Dags as
needed. Here are some examples of arguments:
-* ``execution_date`` if you want to test argument-specific Dag runs
+* ``logical_date`` if you want to test argument-specific Dag runs
* ``use_executor`` if you want to test the Dag using an executor. By default
``dag.test`` runs the Dag without an
executor, it just runs all the tasks locally.
By providing this argument, the Dag is executed using the executor
configured in the Airflow environment.
diff --git a/airflow-core/docs/core-concepts/params.rst
b/airflow-core/docs/core-concepts/params.rst
index 47502db86ad..c192ee639ec 100644
--- a/airflow-core/docs/core-concepts/params.rst
+++ b/airflow-core/docs/core-concepts/params.rst
@@ -349,8 +349,8 @@ The following features are supported in the Trigger UI Form:
| input - because of JSON validation.
| If you want to have a field value being
| added optional only, you must allow
- | JSON schema validation allowing null
- | values.
+ | the null type in the JSON schema
+ | validation.
-
- ``Param(None, type=["null", "string"])``
@@ -400,7 +400,6 @@ The following features are supported in the Trigger UI Form:
- On the bottom of the form the generated JSON configuration can be expanded.
If you want to change values manually, the JSON configuration can be
adjusted. Changes in the JSON will be reflected in the form fields.
- Fields can be required or optional. Typed fields are required by default to
ensure they pass JSON schema validation. To make typed fields optional, you
must allow the "null" type.
-- Fields without a "section" will be rendered in the default area. Additional
sections will be collapsed by default.
.. note::
If the field is required the default value must be valid according to the
schema as well. If the Dag is defined with
@@ -450,7 +449,7 @@ Finally the fourth section shows advanced form elements.
.. versionchanged:: 3.0.0
By default custom HTML is not allowed to prevent injection of scripts or
other malicious HTML code. The previous field named
- ``description_html`` is now super-seeded with the attribute
``description_md``. ``description_html`` is not supported anymore.
+ ``description_html`` is now superseded with the attribute
``description_md``. ``description_html`` is not supported anymore.
Custom form elements using the attribute ``custom_html_form`` was
deprecated in version 2.8.0 and support was removed in 3.0.0.
Disabling Runtime Param Modification
diff --git a/airflow-core/docs/core-concepts/sensors.rst
b/airflow-core/docs/core-concepts/sensors.rst
index 9a2e9b9633f..21c0c5d9353 100644
--- a/airflow-core/docs/core-concepts/sensors.rst
+++ b/airflow-core/docs/core-concepts/sensors.rst
@@ -19,7 +19,7 @@ Sensors
========
Sensors are a special type of :doc:`Operator <operators>` that are designed to
do exactly one thing - wait for something to occur. It can be time-based, or
waiting for a file, or an external event, but all they do is wait until
something happens, and then *succeed* so their downstream tasks can run.
-Or, in the case when that thing does _not_ happen within the configured
timeout, *fails* so that you can be alerted to the failure through the usual
mechanisms.
+Or, in the case when that thing does *not* happen within the configured
timeout, *fails* so that you can be alerted to the failure through the usual
mechanisms.
Because they are primarily idle, Sensors have two different modes of running
so you can be a bit more efficient about using them:
diff --git a/airflow-core/docs/core-concepts/task-state-store.rst
b/airflow-core/docs/core-concepts/task-state-store.rst
index 783a9c0a825..46bd2c88f4c 100644
--- a/airflow-core/docs/core-concepts/task-state-store.rst
+++ b/airflow-core/docs/core-concepts/task-state-store.rst
@@ -56,7 +56,7 @@ Inside any ``@task``-decorated function or
``BaseOperator.execute()`` method, ta
my_value = task_state_store.get("my_key", default="my_default_key")
# Set the new value
- new_value = f"It is {random.randint(1, 12 + 1)} o'clock"
+ new_value = f"It is {random.randint(1, 12)} o'clock"
task_state_store.set("my_key", new_value)
# Delete the value
diff --git a/airflow-core/docs/core-concepts/taskflow.rst
b/airflow-core/docs/core-concepts/taskflow.rst
index 2e91649a381..c96e5c04186 100644
--- a/airflow-core/docs/core-concepts/taskflow.rst
+++ b/airflow-core/docs/core-concepts/taskflow.rst
@@ -102,7 +102,7 @@ a ``Asset``, which is ``@attr.define`` decorated, together
with TaskFlow.
.. note::
- An additional benefit of using ``Asset`` is that it automatically
registers as an ``inlet`` in case it is used as an input argument. It also auto
registers as an ``outlet`` if the return value of your task is a ``Asset`` or a
``list[Asset]]``.
+ An additional benefit of using ``Asset`` is that it automatically
registers as an ``inlet`` in case it is used as an input argument. It also auto
registers as an ``outlet`` if the return value of your task is a ``Asset`` or a
``list[Asset]``.
.. code-block:: python
@@ -177,7 +177,7 @@ yourself. To do so add the ``serialize()`` method to your
class and the staticme
@staticmethod
def deserialize(data: dict, version: int):
if version > 1:
- raise TypeError(f"version > {MyCustom.version}")
+ raise TypeError(f"version > {MyCustom.__version__}")
return MyCustom(data["x"])
Object Versioning
diff --git a/airflow-core/docs/core-concepts/xcoms.rst
b/airflow-core/docs/core-concepts/xcoms.rst
index b61ee9e1744..d1d8fe75ee3 100644
--- a/airflow-core/docs/core-concepts/xcoms.rst
+++ b/airflow-core/docs/core-concepts/xcoms.rst
@@ -23,7 +23,7 @@ XComs
XComs (short for "cross-communications") are a mechanism that let :doc:`tasks`
talk to each other, as by default Tasks are entirely isolated and may be
running on entirely different machines.
-An XCom is identified by a ``key`` (essentially its name), as well as the
``task_id`` and ``dag_id`` it came from. They can have any serializable value
(including objects that are decorated with ``@dataclass`` or ``@attr.define``,
see :ref:`TaskFlow arguments <concepts:arbitrary-arguments>`:), but they are
only designed for small amounts of data; do not use them to pass around large
values, like dataframes.
+An XCom is identified by a ``key`` (essentially its name), as well as the
``task_id`` and ``dag_id`` it came from. They can have any serializable value
(including objects that are decorated with ``@dataclass`` or ``@attr.define``,
see :ref:`TaskFlow arguments <concepts:arbitrary-arguments>`), but they are
only designed for small amounts of data; do not use them to pass around large
values, like dataframes.
XCom operations should be performed through the Task Context using
:func:`~airflow.sdk.get_current_context`. Directly updating using XCom
database model is not possible.
diff --git a/airflow-core/docs/extra-packages-ref.rst
b/airflow-core/docs/extra-packages-ref.rst
index 5c285ebb7d6..bb00925002a 100644
--- a/airflow-core/docs/extra-packages-ref.rst
+++ b/airflow-core/docs/extra-packages-ref.rst
@@ -118,7 +118,7 @@ other packages that can be used by airflow or some of its
providers.
+---------------------+-----------------------------------------------------+----------------------------------------------------------------------------+
| amazon-aws-auth | ``pip install apache-airflow[amazon-aws-auth]`` |
Amazon-aws-auth AWS authentication |
+---------------------+-----------------------------------------------------+----------------------------------------------------------------------------+
-| cloudpickle | ``pip install apache-airflow[cloudpickle]`` |
Cloudpickle hooks and operators |
+| cloudpickle | ``pip install apache-airflow[cloudpickle]`` |
Cloudpickle serialization support |
+---------------------+-----------------------------------------------------+----------------------------------------------------------------------------+
| github-enterprise | ``pip install 'apache-airflow[github-enterprise]'`` |
GitHub Enterprise auth backend |
+---------------------+-----------------------------------------------------+----------------------------------------------------------------------------+
diff --git a/airflow-core/docs/faq.rst b/airflow-core/docs/faq.rst
index 2719f463416..e9104117042 100644
--- a/airflow-core/docs/faq.rst
+++ b/airflow-core/docs/faq.rst
@@ -73,7 +73,7 @@ There are very many reasons why your task might not be
getting scheduled. Here a
running. You can bulk view the list of DagRuns and alter states by clicking
on the schedule tag for a Dag.
-- Is the ``concurrency`` parameter of your Dag reached? ``concurrency`` defines
+- Is the ``max_active_tasks`` parameter of your Dag reached?
``max_active_tasks`` defines
how many ``running`` task instances a Dag is allowed to have, beyond which
point things get queued.
@@ -87,18 +87,18 @@ sure you fully understand how the scheduler cycle works.
How to improve Dag performance?
-------------------------------
-There are some Airflow configuration to allow for a larger scheduling capacity
and frequency:
+There are some Airflow configurations to allow for a larger scheduling
capacity and frequency:
- :ref:`config:core__parallelism`
- :ref:`config:core__max_active_tasks_per_dag`
- :ref:`config:core__max_active_runs_per_dag`
-Dags have configurations that improves efficiency:
+Dags have configurations that improve efficiency:
- ``max_active_tasks``: Overrides :ref:`config:core__max_active_tasks_per_dag`.
- ``max_active_runs``: Overrides :ref:`config:core__max_active_runs_per_dag`.
-Operators or tasks also have configurations that improves efficiency and
scheduling priority:
+Operators or tasks also have configurations that improve efficiency and
scheduling priority:
- ``max_active_tis_per_dag``: This parameter controls the number of concurrent
running task instances across ``dag_runs``
per task.
@@ -585,7 +585,7 @@ and eventually cause Dag file processing to fail.
Refer to :ref:`Dag writing best practices<best_practice:writing_a_dag>` for
more information.
-Do Macros resolves in another Jinja template?
+Do Macros resolve in another Jinja template?
---------------------------------------------
It is not possible to render :ref:`Macros<macros>` or any Jinja template
within another Jinja template. This is
diff --git a/airflow-core/docs/howto/connection.rst
b/airflow-core/docs/howto/connection.rst
index ced1baa6aa9..9253442b550 100644
--- a/airflow-core/docs/howto/connection.rst
+++ b/airflow-core/docs/howto/connection.rst
@@ -200,7 +200,7 @@ You can add a connection using JSON format (from version
2.3.0):
}
}'
-Alternatively you may use Airflow' Connection URI format (see :ref:`Generating
a Connection URI <generating_connection_uri>`).
+Alternatively you may use Airflow's Connection URI format (see
:ref:`Generating a Connection URI <generating_connection_uri>`).
.. code-block:: bash
diff --git a/airflow-core/docs/howto/custom-operator.rst
b/airflow-core/docs/howto/custom-operator.rst
index f6793d4e8d0..d12892355b1 100644
--- a/airflow-core/docs/howto/custom-operator.rst
+++ b/airflow-core/docs/howto/custom-operator.rst
@@ -450,7 +450,7 @@ that your sensor is not suitable for use with reschedule
mode.
An example of a sensor that keeps internal state and cannot be used with
reschedule mode
is
:class:`airflow.providers.google.cloud.sensors.gcs.GCSUploadSessionCompleteSensor`.
It polls the number of objects at a prefix (this number is the internal state
of the sensor)
-and succeeds when there a certain amount of time has passed without the number
of objects changing.
+and succeeds when there has been a certain amount of time passed without the
number of objects changing.
Testing your operator
---------------------
diff --git a/airflow-core/docs/howto/custom-view-plugin.rst
b/airflow-core/docs/howto/custom-view-plugin.rst
index 024c32f9613..dcab538833e 100644
--- a/airflow-core/docs/howto/custom-view-plugin.rst
+++ b/airflow-core/docs/howto/custom-view-plugin.rst
@@ -42,7 +42,7 @@ in the Airflow UI. This is useful for integrating external
applications or custo
In this object reference, the list of dictionaries with the view name, href
(templatable), destination and
optional parameters like the icon and url_route are passed on.
-Using react_apps in Airflow plugin, allows to register custom React
applications that can be rendered
+Using react_apps in Airflow plugin, allows to register custom React
applications that can be rendered
in the Airflow UI. This is useful for integrating custom React components or
applications into the Airflow UI.
In this object reference, the list of dictionaries with the app name,
bundle_url (where to load the js assets, templatable), destination and
optional parameters like the icon and url_route are passed on.
diff --git a/airflow-core/docs/howto/define-extra-link.rst
b/airflow-core/docs/howto/define-extra-link.rst
index 39991759300..92bafba2aea 100644
--- a/airflow-core/docs/howto/define-extra-link.rst
+++ b/airflow-core/docs/howto/define-extra-link.rst
@@ -74,7 +74,7 @@ You can see all the extra links available via
community-managed providers in
Add or override Links to Existing Operators
-------------------------------------------
-You can also add (or override) an extra link to an existing operators
+You can also add (or override) an extra link to existing operators
through an Airflow plugin or custom provider.
For example, the following Airflow plugin will add an Operator Link on all
diff --git a/airflow-core/docs/howto/docker-compose/index.rst
b/airflow-core/docs/howto/docker-compose/index.rst
index aa61ed3a8bd..e83e45df5b9 100644
--- a/airflow-core/docs/howto/docker-compose/index.rst
+++ b/airflow-core/docs/howto/docker-compose/index.rst
@@ -247,7 +247,7 @@ You can also run :doc:`CLI commands <../usage-cli>`, but
you have to do it in on
docker compose run airflow-worker airflow info
-If you have Linux or Mac OS, you can make your work easier and download a
optional wrapper scripts that will allow you to run commands with a simpler
command.
+If you have Linux or Mac OS, you can make your work easier and download an
optional wrapper script that will allow you to run commands with a simpler
command.
.. jinja:: quick_start_ctx
@@ -472,7 +472,7 @@ runtime user id which is unknown at the time of building
the image.
| | it should be set to result of ``id -u``
call. | |
| | When it is changed, a user with the UID is
| |
| | created with ``default`` name inside the
container | |
-| | and home of the use is set to
``/airflow/home/`` | |
+| | and home of the user is set to
``/airflow/home/`` | |
| | in order to share Python libraries
installed there. | |
| | This is in order to achieve the OpenShift
| |
| | compatibility. See more in the
| |
diff --git a/airflow-core/docs/howto/export-more-env-vars.rst
b/airflow-core/docs/howto/export-more-env-vars.rst
index a35b3be6fb5..4cbc55c593a 100644
--- a/airflow-core/docs/howto/export-more-env-vars.rst
+++ b/airflow-core/docs/howto/export-more-env-vars.rst
@@ -25,7 +25,7 @@ Export dynamic environment variables available for operators
to use
The key value pairs returned in ``get_airflow_context_vars`` defined in
``airflow_local_settings.py`` are injected to default Airflow context
environment variables,
which are available as environment variables when running tasks. Note, both
key and
-value are must be string.
+value must be strings.
``dag_id``, ``task_id``, ``execution_date``, ``dag_run_id``,
``dag_owner``, ``dag_email`` are reserved keys.
diff --git a/airflow-core/docs/howto/memory-profiling.rst
b/airflow-core/docs/howto/memory-profiling.rst
index 83f6e976f79..197f9249c73 100644
--- a/airflow-core/docs/howto/memory-profiling.rst
+++ b/airflow-core/docs/howto/memory-profiling.rst
@@ -240,7 +240,7 @@ Precautions
1. **Profile in Non-Production Environments**
Memory profiling adds significant overhead, including increased memory
usage and performance
- degradation. Use it in development that mirror your production setup.
+ degradation. Use it in a development environment that mirrors your
production setup.
2. **Use Representative Workloads**
Ensure the workload you're profiling is representative of your actual use
case.
diff --git a/airflow-core/docs/howto/run-behind-proxy.rst
b/airflow-core/docs/howto/run-behind-proxy.rst
index 419b8506d4b..ae28cb23b33 100644
--- a/airflow-core/docs/howto/run-behind-proxy.rst
+++ b/airflow-core/docs/howto/run-behind-proxy.rst
@@ -33,7 +33,7 @@ To do so, you need to set the following setting in your
``airflow.cfg``::
base_url = http://my_host/myorg/airflow
-- Configure your reverse proxy (e.g. nginx) to pass the url and http header
as it for the Airflow webserver, without any rewrite, for example::
+- Configure your reverse proxy (e.g. nginx) to pass the url and http header
as-is to the Airflow webserver, without any rewrite, for example::
server {
listen 80;
diff --git a/airflow-core/docs/howto/set-config.rst
b/airflow-core/docs/howto/set-config.rst
index 7a982584593..b4fcf0559c2 100644
--- a/airflow-core/docs/howto/set-config.rst
+++ b/airflow-core/docs/howto/set-config.rst
@@ -181,7 +181,7 @@ Some Airflow configuration is configured via local setting,
because they require
code that is executed when Airflow is initialized. Usually it is mentioned in
the detailed documentation
where you can configure such local settings - This is usually done in the
``airflow_local_settings.py`` file.
-You should create a ``airflow_local_settings.py`` file and put it in a
directory in ``sys.path`` or
+You should create an ``airflow_local_settings.py`` file and put it in a
directory in ``sys.path`` or
in the ``$AIRFLOW_HOME/config`` folder. (Airflow adds ``$AIRFLOW_HOME/config``
to ``sys.path`` when
Airflow is initialized)
Starting from Airflow 2.10.1, the $AIRFLOW_HOME/dags folder is no longer
included in sys.path at initialization, so any local settings in that folder
will not be imported. Ensure that airflow_local_settings.py is located in a
path that is part of sys.path during initialization, like $AIRFLOW_HOME/config.
diff --git a/airflow-core/docs/howto/set-up-database.rst
b/airflow-core/docs/howto/set-up-database.rst
index 4fd02a5fc75..af99862839a 100644
--- a/airflow-core/docs/howto/set-up-database.rst
+++ b/airflow-core/docs/howto/set-up-database.rst
@@ -159,7 +159,7 @@ Setting up a PostgreSQL Database
--------------------------------
You need to create a database and a database user that Airflow will use to
access this database.
-In the example below, a database ``airflow_db`` and user with username
``airflow_user`` with password ``airflow_pass`` will be created
+In the example below, a database ``airflow_db`` and a user with username
``airflow_user`` with password ``airflow_pass`` will be created
.. code-block:: sql
@@ -341,7 +341,7 @@ Setting up a MySQL Database
---------------------------
You need to create a database and a database user that Airflow will use to
access this database.
-In the example below, a database ``airflow_db`` and user with username
``airflow_user`` with password ``airflow_pass`` will be created
+In the example below, a database ``airflow_db`` and a user with username
``airflow_user`` with password ``airflow_pass`` will be created
.. code-block:: sql
diff --git a/airflow-core/docs/howto/setup-and-teardown.rst
b/airflow-core/docs/howto/setup-and-teardown.rst
index cc7ec1c9c95..813297295da 100644
--- a/airflow-core/docs/howto/setup-and-teardown.rst
+++ b/airflow-core/docs/howto/setup-and-teardown.rst
@@ -131,8 +131,8 @@ Implicit ALL_SUCCESS constraint
Any task in the scope of a setup has an implicit "all_success" constraint on
its setups.
This is necessary to ensure that if a task with indirect setups is cleared, it
will
-wait for them to complete. If a setup fails or is skipped, the work tasks
which depend
-them will be marked ask failures or skips. We also require that any
non-teardown directly
+wait for them to complete. If a setup fails or is skipped, the work tasks
which depend on
+them will be marked as failures or skips. We also require that any
non-teardown directly
downstream of a setup must have trigger rule ALL_SUCCESS.
Controlling Dag run state
diff --git a/airflow-core/docs/howto/sla-to-deadlines.rst
b/airflow-core/docs/howto/sla-to-deadlines.rst
index ccfe602360b..7e5b4dd6f3c 100644
--- a/airflow-core/docs/howto/sla-to-deadlines.rst
+++ b/airflow-core/docs/howto/sla-to-deadlines.rst
@@ -21,7 +21,7 @@ Migrating from SLA to Deadline Alerts
Two Different Paradigms
-----------------------
-While the goal of the **SLA** and **Deadline Alerts** features are very
similar, they use two very different approaches.
+While the goals of the **SLA** and **Deadline Alerts** features are very
similar, they use two very different approaches.
This guide will lay out the major differences and help you decide on the best
approach for your use case.
To begin with, we'll start by explaining the two approaches then go into how
to find the right Deadline for your use case.
diff --git a/airflow-core/docs/howto/timetable.rst
b/airflow-core/docs/howto/timetable.rst
index 38e28cc0cd3..062be319a13 100644
--- a/airflow-core/docs/howto/timetable.rst
+++ b/airflow-core/docs/howto/timetable.rst
@@ -269,7 +269,7 @@ serialized Dag is accessed by the scheduler to reconstruct
the timetable.
Timetable Display in UI
-----------------------
-By default, a custom timetable is displayed by their class name in the UI (e.g.
+By default, a custom timetable is displayed by its class name in the UI (e.g.
the *Schedule* column in the "dags" table). It is possible to customize this
by overriding the ``summary`` property. This is especially useful for
parameterized timetables to include arguments provided in ``__init__``. For
@@ -321,7 +321,7 @@ You can also wrap this inside ``__init__``, if you want to
derive description.
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.
+This is especially useful when you want to provide comprehensive description
which is different from ``summary`` property.
So for a Dag declared like this:
@@ -347,7 +347,7 @@ Changing generated ``run_id``
Since Airflow 2.4, Timetables are also responsible for generating the
``run_id`` for DagRuns.
-For example to have the Run ID show a "human friendly" date of when the run
started (that is, the end of the data interval, rather then the start which is
the date currently used) you could add a method like this to a custom timetable:
+For example to have the Run ID show a "human friendly" date of when the run
started (that is, the end of the data interval, rather than the start which is
the date currently used) you could add a method like this to a custom timetable:
.. code-block:: python
diff --git a/airflow-core/docs/installation/dependencies.rst
b/airflow-core/docs/installation/dependencies.rst
index 8e209869abb..64b9e1dc1ca 100644
--- a/airflow-core/docs/installation/dependencies.rst
+++ b/airflow-core/docs/installation/dependencies.rst
@@ -39,8 +39,8 @@ Provider distributions
''''''''''''''''''''''
Airflow is delivered in multiple, separate, but connected packages. There is
the main ``apache-airflow``
-package, ``airflow-core`` package (which is a dependency of
``apache-airflow``) which implements
-main airflow functionality, ``airflow-task-sdk`` package that is used by Dag
authors to implement Dags,
+package, ``apache-airflow-core`` package (which is a dependency of
``apache-airflow``) which implements
+main airflow functionality, ``apache-airflow-task-sdk`` package that is used
by Dag authors to implement Dags,
and multiple so called ``Airflow providers`` packages.
The default Airflow installation doesn't have many integrations and you have
to install them yourself.
@@ -62,12 +62,12 @@ packages, but not all optional features of Apache Airflow
have corresponding pro
We are using the ``extras`` setuptools features to also install providers.
Most of the extras are also linked (same name) with providers - for example
using ``apache-airflow[google]``
-extra installs ``airflow-core`` and adds ``apache-airflow-providers-google``
as dependency.
-However, there are some extras that do not install providers (examples
``github_enterprise``, ``kerberos`` -
+extra installs ``apache-airflow-core`` and adds
``apache-airflow-providers-google`` as dependency.
+However, there are some extras that do not install providers (examples
``github_enterprise``, ``kerberos``) -
they add some extra dependencies which are needed for those ``extra`` features
of
-Airflow mentioned. The three examples above add respectively GitHub Enterprise
OAuth authentication,
-Kerberos integration . None of those have providers, they are just extending
Apache Airflow
-``airflow-core`` package with new functionalities.
+Airflow mentioned. The two examples above add respectively GitHub Enterprise
OAuth authentication and
+Kerberos integration. None of those have providers, they are just extending
Apache Airflow
+``apache-airflow-core`` package with new functionalities.
System dependencies
'''''''''''''''''''
diff --git a/airflow-core/docs/installation/index.rst
b/airflow-core/docs/installation/index.rst
index c3737c15bd6..87fd0b52420 100644
--- a/airflow-core/docs/installation/index.rst
+++ b/airflow-core/docs/installation/index.rst
@@ -59,7 +59,7 @@ you can install Airflow directly from PyPI with the command
below:
pipx run apache-airflow standalone
-Alternatively similar with Astral ``uv``:
+Alternatively, you can do something similar with Astral ``uv``:
.. code-block:: bash
@@ -395,7 +395,7 @@ control theory - where there are two types of systems:
the system and adjust the knobs continuously to make sure the system is
running smoothly.
Airflow (and generally any modern systems running usually on cloud services,
with multiple layers responsible
-for resources as well multiple parameters to control their behaviour) is a
complex system and it fall
+for resources as well multiple parameters to control their behaviour) is a
complex system and it falls
much more in the second category. If you decide to run Airflow in production
on your own, you should be
prepared for the monitor/observe/adjust feedback loop to make sure the system
is running smoothly.
diff --git a/airflow-core/docs/installation/installing-from-sources.rst
b/airflow-core/docs/installation/installing-from-sources.rst
index f807fa96ec1..627d1831d4b 100644
--- a/airflow-core/docs/installation/installing-from-sources.rst
+++ b/airflow-core/docs/installation/installing-from-sources.rst
@@ -29,14 +29,14 @@ Released packages
the top-left of the page.
The Source packages are official packages of the Apache Software Foundation -
and the ones that you can
-use is you want to build the packages yourself from the source code and be
sure that the provenance of
+use if you want to build the packages yourself from the source code and be
sure that the provenance of
the packages is verified and matches the source code from the repository and
you can verify the
checksums and signatures of the packages.
-The ``sdist`` and ``whl`` packages released are the convenience packages - of
installation also installed from
+The ``sdist`` and ``whl`` packages released are the convenience packages - for
installation, also built from
the same sources and you can still verify the origin of the packages and want
to verify checksums and
-signatures of the packages. The packages are available via the Official Apache
Software Foundations Downloads
-`Official Apache Software Foundations Downloads <https://dlcdn.apache.org/>`_
+signatures of the packages. The packages are available via the
+`Official Apache Software Foundation Downloads <https://dlcdn.apache.org/>`_
The ``|version|`` downloads of Airflow® are available at:
@@ -51,7 +51,7 @@ The ``|version|`` downloads of Airflow® are available at:
* `Whl package for airflow task-sdk distribution <{{
closer_lua_url_task_sdk }}/apache_airflow_task_sdk-{{ task_sdk_version
}}-py3-none-any.whl>`__ (`asc <{{ base_url_task_sdk
}}/apache_airflow_task_sdk-{{ task_sdk_version }}-py3-none-any.whl.asc>`__,
`sha512 <{{ base_url_task_sdk }}/apache_airflow_task_sdk-{{ task_sdk_version
}}-py3-none-any.whl.sha512>`__)
If you want to install from the source code, you can download from the sources
link above, it will contain
-a ``INSTALL`` file containing details on how you can build and install Airflow.
+an ``INSTALL`` file containing details on how you can build and install
Airflow.
Release integrity
'''''''''''''''''
diff --git a/airflow-core/docs/installation/upgrading.rst
b/airflow-core/docs/installation/upgrading.rst
index 50822bae775..8e91f80b5c7 100644
--- a/airflow-core/docs/installation/upgrading.rst
+++ b/airflow-core/docs/installation/upgrading.rst
@@ -89,7 +89,7 @@ Handling migration problems
Wrong Encoding in MySQL database
................................
-If you are using old Airflow 1.10 as a database created initially either
manually or with previous version of MySQL,
+If you have an old Airflow 1.10 database that was created initially either
manually or with a previous version of MySQL,
depending on the original character set of your database, you might have
problems with migrating to a newer
version of Airflow and your migration might fail with strange errors ("key
size too big", "missing indexes" etc).
The next chapter describes how to fix the problem manually.
diff --git a/airflow-core/docs/installation/upgrading_to_airflow3.rst
b/airflow-core/docs/installation/upgrading_to_airflow3.rst
index 91e86cb3ccb..cd32d05d629 100644
--- a/airflow-core/docs/installation/upgrading_to_airflow3.rst
+++ b/airflow-core/docs/installation/upgrading_to_airflow3.rst
@@ -119,7 +119,7 @@ To trigger these fixes, run the following command:
.. note::
In AIR rules, unsafe fixes involve changing import paths while keeping the
name of the imported member the same. For instance, changing the import from
``from airflow.sensors.base_sensor_operator import BaseSensorOperator`` to
``from airflow.sdk.bases.sensor import BaseSensorOperator`` requires ruff to
remove the original import before adding the new one. In contrast, safe fixes
include changes to both the member name and the import path, such as changing
``from airflow.datasets impo [...]
- These adjustments do not require ruff to remove the old import. To remove
unused legacy imports, it is necessary to enable the ``unused-import`` rule
(F401) <https://docs.astral.sh/ruff/rules/unused-import/#unused-import-f401>`_
+ These adjustments do not require ruff to remove the old import. To remove
unused legacy imports, it is necessary to enable the `unused-import rule (F401)
<https://docs.astral.sh/ruff/rules/unused-import/#unused-import-f401>`_
You can also configure these flags through configuration files. See
`Configuring Ruff <https://docs.astral.sh/ruff/configuration/>`_ for details.
diff --git a/airflow-core/docs/public-airflow-interface.rst
b/airflow-core/docs/public-airflow-interface.rst
index 3d9dccf577c..756ea2e8bc0 100644
--- a/airflow-core/docs/public-airflow-interface.rst
+++ b/airflow-core/docs/public-airflow-interface.rst
@@ -33,8 +33,7 @@ and extending Airflow capabilities by writing new executors,
plugins, operators
Public Interface can be useful for building custom tools and integrations with
other systems,
and for automating certain aspects of the Airflow workflow.
-The primary public interface for Dag authors and task execution is using task
SDK
-Airflow task SDK is the primary public interface for Dag authors and for task
execution
+The primary public interface for Dag authors and for task execution is the
Airflow Task SDK, via the
:doc:`airflow.sdk namespace <core-concepts/taskflow>`. Direct access to the
metadata database
from task code is no longer allowed. Instead, use the :doc:`Stable REST API
<stable-rest-api-ref>`,
`Python Client <https://github.com/apache/airflow-client-python>`_, or Task
Context methods.
@@ -61,7 +60,7 @@ Using Airflow Public Interfaces
The following are some examples of the public interface of Airflow:
-* When you are writing your own operators or hooks. This is commonly done when
no hook or operator exists for your use case, or when perhaps when one exists
but you need to customize the behavior.
+* When you are writing your own operators or hooks. This is commonly done when
no hook or operator exists for your use case, or perhaps when one exists but
you need to customize the behavior.
* When writing new :doc:`Plugins <administration-and-deployment/plugins>` that
extend Airflow's functionality beyond
Dag building blocks. Secrets, Timetables, Triggers, Listeners are all
examples of such functionality. This
is usually done by users who manage Airflow instances.
@@ -71,7 +70,7 @@ The following are some examples of the public interface of
Airflow:
* Using the taskflow API to write tasks
* Relying on the consistent behavior of Airflow objects
-One aspect of "public interface" is extending or using Airflow Python classes
and functions. The classes
+One aspect of "public interface" is extending or using Airflow Python classes
and functions. The classes
and functions mentioned below can be relied on to maintain
backwards-compatible signatures and behaviours within
MAJOR version of Airflow. On the other hand, classes and methods starting with
``_`` (also known
as protected Python methods) and ``__`` (also known as private Python methods)
are not part of the Public
diff --git a/airflow-core/docs/security/audit_logs.rst
b/airflow-core/docs/security/audit_logs.rst
index 3c7df803cb0..947c0c0eee4 100644
--- a/airflow-core/docs/security/audit_logs.rst
+++ b/airflow-core/docs/security/audit_logs.rst
@@ -89,7 +89,7 @@ While both logging systems are crucial for system management,
they serve distinc
- Short to medium-term (days to weeks)
* - **Query Patterns**
- "Who cleared the task instance for re-execution?"
- - No query made except is a log aggregation framework is used. Usually
logs are read on a per task execution basis and will describe: "Why did this
task execution fail?"
+ - No query is made unless a log aggregation framework is used. Usually
logs are read on a per task execution basis and will describe: "Why did this
task execution fail?"
Accessing Audit Logs
@@ -486,16 +486,16 @@ Effective audit log analysis requires understanding the
various methods availabl
.. code-block:: bash
# Get all audit logs
- curl -X GET "http://localhost:8080/api/v1/eventLogs";
+ curl -X GET "http://localhost:8080/api/v2/eventLogs";
# Filter by event type
- curl -X GET "http://localhost:8080/api/v1/eventLogs?event=trigger_dag_run";
+ curl -X GET "http://localhost:8080/api/v2/eventLogs?event=trigger_dag_run";
# Filter by DAG
- curl -X GET "http://localhost:8080/api/v1/eventLogs?dag_id=example_dag";
+ curl -X GET "http://localhost:8080/api/v2/eventLogs?dag_id=example_dag";
# Filter by date range
- curl -X GET
"http://localhost:8080/api/v1/eventLogs?after=2024-01-01T00:00:00Z&before=2024-12-31T23:59:59Z";
+ curl -X GET
"http://localhost:8080/api/v2/eventLogs?after=2024-01-01T00:00:00Z&before=2024-12-31T23:59:59Z";
**Database Query Examples**:
@@ -544,10 +544,10 @@ Event logs (operational logs) are typically accessed
through different methods d
.. code-block:: bash
# Get task instance logs
- curl -X GET
"http://localhost:8080/api/v1/dags/{dag_id}/dagRuns/{dag_run_id}/taskInstances/{task_id}/logs/{try_number}";
+ curl -X GET
"http://localhost:8080/api/v2/dags/{dag_id}/dagRuns/{dag_run_id}/taskInstances/{task_id}/logs/{try_number}";
# Get task logs with metadata
- curl -X GET
"http://localhost:8080/api/v1/dags/example_dag/dagRuns/2024-01-01T00:00:00+00:00/taskInstances/example_task/logs/1?full_content=true";
+ curl -X GET
"http://localhost:8080/api/v2/dags/example_dag/dagRuns/2024-01-01T00:00:00+00:00/taskInstances/example_task/logs/1?full_content=true";
**Python Logging Integration**:
diff --git a/airflow-core/docs/security/kerberos.rst
b/airflow-core/docs/security/kerberos.rst
index 6de9b65e161..7c6be7a2f21 100644
--- a/airflow-core/docs/security/kerberos.rst
+++ b/airflow-core/docs/security/kerberos.rst
@@ -101,7 +101,7 @@ If you need more granular options for your Kerberos ticket
the following options
with mode ``0700`` and owned by the Airflow user. Apply the same principle
as the keytab, which
should already be ``chmod 600``.
-Keep in mind that Kerberos ticket are generated via ``kinit`` and will your
use your local ``krb5.conf`` by default.
+Keep in mind that Kerberos tickets are generated via ``kinit`` and will use
your local ``krb5.conf`` by default.
Launch the ticket renewer by
@@ -136,7 +136,7 @@ For one time mode:
Hadoop
^^^^^^
-If want to use impersonation this needs to be enabled in ``core-site.xml`` of
your hadoop config.
+If you want to use impersonation, this needs to be enabled in
``core-site.xml`` of your hadoop config.
.. code-block:: xml
diff --git a/airflow-core/docs/security/security_model.rst
b/airflow-core/docs/security/security_model.rst
index c9a0b91b932..f59abe1bcbc 100644
--- a/airflow-core/docs/security/security_model.rst
+++ b/airflow-core/docs/security/security_model.rst
@@ -116,7 +116,7 @@ to abuse these privileges. They have access to sensitive
credentials
and can modify them. By default, they don't have access to
system-level configuration. They should be trusted not to misuse
sensitive information accessible through connection configuration.
-They also have the ability to create a API Server Denial of Service
+They also have the ability to create an API Server Denial of Service
situation and should be trusted not to misuse this capability.
Only admin users have access to audit logs by default.
@@ -138,7 +138,7 @@ required to prevent misuse of these privileges. They have
full write-only access
to sensitive credentials stored in connections and can modify them, but cannot
view them.
Access to write sensitive information through connection configuration
should be trusted not to be abused. They also have the ability to configure
connections wrongly
-that might create a API Server Denial of Service situations and specify
insecure connection options
+that might create an API Server Denial of Service situation and specify
insecure connection options
which might create situations where executing Dags will lead to arbitrary
Remote Code Execution
for some providers - either community released or custom ones.
@@ -898,7 +898,7 @@ up to the Deployment Manager - Airflow does not provide any
tooling or mechanism
expects that the Deployment Manager will provide the tooling to protect access
to Dag bundles and
make sure that only trusted code is submitted there.
-Airflow does not implement any of those feature natively, and delegates it to
the deployment managers
+Airflow does not implement any of those features natively, and delegates it to
the deployment managers
to deploy all the necessary infrastructure to protect the deployment - as
external infrastructure components.
Limiting access for authenticated UI users
@@ -1208,7 +1208,7 @@ Supported deployment platforms
Apache Airflow officially supports Linux-based deployment environments only.
The reference
deployment, the CI matrix, and the official Docker image are all
Linux-targeted (Debian Bookworm).
macOS is supported for local development but is not a deployment platform.
Windows is not supported
-for deployment - except WSL2 for develop (buy only with POSIX filesystem which
is the same as Linux).
+for deployment - except WSL2 for development (but only with POSIX filesystem
which is the same as Linux).
Vulnerability reports that only manifest on a non-Linux platform — behavior
that depends on Windows
path separators, macOS-specific filesystem semantics, etc. — are **out of
scope** for the security
diff --git a/airflow-core/docs/security/sql.rst
b/airflow-core/docs/security/sql.rst
index b6b81d2180c..fed3981f5fd 100644
--- a/airflow-core/docs/security/sql.rst
+++ b/airflow-core/docs/security/sql.rst
@@ -19,7 +19,7 @@ SQL Injection
=============
Previously, Airflow issued CVE like `CVE-2025-27018 SQL injection in MySQL
provider core function <https://www.cve.org/CVERecord?id=CVE-2025-27018/>`_.
-The CVE were about the ability to inject SQL without considering the actor
performing it.
+The CVE was about the ability to inject SQL without considering the actor
performing it.
Airflow will no longer issue CVE for cases of SQL Injection unless the
reporter can demonstrate a scenario of exploitation.
For example, if in a security report the only actor that can operate the
injection is Actor who has access to Dags folder the report will be rejected.
When submitting a security report of SQL injection the reporter must explain
who is the user that can utilize the injection and how the user gained access
to be able to perform it.
diff --git
a/airflow-core/docs/security/vulnerabilities-in-3rd-party-dependencies.rst
b/airflow-core/docs/security/vulnerabilities-in-3rd-party-dependencies.rst
index 6247a4032df..810a0b3621f 100644
--- a/airflow-core/docs/security/vulnerabilities-in-3rd-party-dependencies.rst
+++ b/airflow-core/docs/security/vulnerabilities-in-3rd-party-dependencies.rst
@@ -91,7 +91,7 @@ used by Airflow and you would like to get rid of those. There
are a few things y
dependency. That helps other community members to be more confident about
upgrading and might make them
aware of some of 3rd-party vulnerabilities that they were not aware of.
-* In case your version of Airflow or some of it's providers, prevent you from
upgrading to a non-vulnerable version of the
+* In case your version of Airflow or some of its providers prevent you from
upgrading to a non-vulnerable version of the
dependency, you can see if latest versions of Airflow or providers removed
any limitations - you can check
constraint files and :doc:`sbom` we publish for all Airflow versions
(industry-standard way of capturing
inventory of dependencies). If you see that you can upgrade, upgrade -
ideally - to latest versions of
diff --git a/airflow-core/docs/start.rst b/airflow-core/docs/start.rst
index c155662a600..7768fa153fc 100644
--- a/airflow-core/docs/start.rst
+++ b/airflow-core/docs/start.rst
@@ -113,7 +113,7 @@ before running ``pip install`` commands:
PYTHON_VERSION="$(python -c 'import sys;
print(f"{sys.version_info.major}.{sys.version_info.minor}")')"
CONSTRAINT_URL="https://raw.githubusercontent.com/apache/airflow/constraints-${AIRFLOW_VERSION}/constraints-${PYTHON_VERSION}.txt";
- # For example this would install 3.0.0 with python 3.10:
https://raw.githubusercontent.com/apache/airflow/constraints-|version|/constraints-3.10.txt
+ # For example this would install 3.1.1 with python 3.10:
https://raw.githubusercontent.com/apache/airflow/constraints-|version|/constraints-3.10.txt
uv pip install "apache-airflow==${AIRFLOW_VERSION}" --constraint
"${CONSTRAINT_URL}"
diff --git a/airflow-core/docs/templates-ref.rst
b/airflow-core/docs/templates-ref.rst
index aeb907dbe47..7012b439979 100644
--- a/airflow-core/docs/templates-ref.rst
+++ b/airflow-core/docs/templates-ref.rst
@@ -20,7 +20,8 @@
Templates reference
===================
-Variables, macros and filters can be used in templates (see the
:ref:`concepts:jinja-templating` section)
+Variables, macros and filters can be used in templates (see the
:ref:`concepts:jinja-templating` section).
+
Asset-triggered DAGs
--------------------
@@ -60,9 +61,10 @@ Variable Type
Description
``{{ logical_date }}`` `pendulum.DateTime`_ | A
date-time that logically identifies the current Dag run. This value does not
contain any semantics, but is simply a value for identification.
| Use
``data_interval_start`` and ``data_interval_end`` instead if you want a value
that has real-world semantics,
| such as to
get a slice of rows from the database based on timestamps.
-``{{ exception }}`` None | str | | Error
occurred while running task instance.
- Exception |
- KeyboardInterrupt |
+``{{ exception }}`` None Error
occurred while running task instance.
+ | str
+ | Exception
+ | KeyboardInterrupt
``{{ prev_data_interval_start_success }}`` `pendulum.DateTime`_ | Start of
the data interval of the prior successful
:class:`~airflow.models.dagrun.DagRun`.
| ``None`` | Added in
version 2.2.
``{{ prev_data_interval_end_success }}`` `pendulum.DateTime`_ | End of the
data interval of the prior successful :class:`~airflow.models.dagrun.DagRun`.
diff --git a/airflow-core/docs/tutorial/fundamentals.rst
b/airflow-core/docs/tutorial/fundamentals.rst
index 14ecb5bf77c..d2ea578dff1 100644
--- a/airflow-core/docs/tutorial/fundamentals.rst
+++ b/airflow-core/docs/tutorial/fundamentals.rst
@@ -213,7 +213,7 @@ Working with Time Zones
Creating a time zone aware Dag is straightforward. Just ensure you use time
zone aware dates
with `pendulum <https://github.com/python-pendulum/pendulum>`_. Avoid using
the standard library
-`timezone <https://docs.python.org/3/library/datetime.html#timezone-objects>`_
as they have known limitations.
+`timezone <https://docs.python.org/3/library/datetime.html#timezone-objects>`_
as it has known limitations.
Recap
-----
diff --git a/airflow-core/docs/tutorial/hitl.rst
b/airflow-core/docs/tutorial/hitl.rst
index aea843486f4..cc09ef7d5b3 100644
--- a/airflow-core/docs/tutorial/hitl.rst
+++ b/airflow-core/docs/tutorial/hitl.rst
@@ -34,7 +34,7 @@ This powerful feature enables workflows to pause and wait for
human input, makin
A waiting ``awaiting_input`` task does not occupy a pool slot. This differs
from the older deferral
path, where a deferred HITL task counted against a pool that had
``include_deferred`` enabled.
-In this tutorial, we will explore how to use the HITL operators in workflows
and demonstrate how it would look like in Airflow UI.
+In this tutorial, we will explore how to use the HITL operators in workflows
and demonstrate what it would look like in the Airflow UI.
An HITL Example Dag
-------------------
@@ -107,7 +107,7 @@ Approval or Rejection
A specialized form of option selection, which has only 'Approval' and
'Rejection' as options.
You can also set the ``assigned_users`` to restrict the users allowed to
respond for a HITL operator.
-It should be a list of user ids and user names (both needed) (e.g., ``[{"id":
"1", "name": "user1"}, {"id": "2", "name": "user2"}]``.
+It should be a list of user ids and user names (both needed) (e.g., ``[{"id":
"1", "name": "user1"}, {"id": "2", "name": "user2"}]``).
ONLY the users within this list will be allowed to respond.
.. exampleinclude::
/../../providers/standard/src/airflow/providers/standard/example_dags/example_hitl_operator.py
diff --git a/airflow-core/docs/ui.rst b/airflow-core/docs/ui.rst
index 23df5ce29b3..867322f91ec 100644
--- a/airflow-core/docs/ui.rst
+++ b/airflow-core/docs/ui.rst
@@ -482,12 +482,12 @@ The Asset List shows all known assets, grouped by name.
For each asset, you can
Hovering over a count of Dags or tasks shows a tooltip with the full list of
producers or consumers.
.. image:: img/ui-dark/asset_list_consuming_dags.png
- :alt: Asset Graph View (dark mode)
+ :alt: Asset List (dark mode)
|
.. image:: img/ui-light/asset_list_consuming_dags.png
- :alt: Asset Graph View (light mode)
+ :alt: Asset List (light mode)
Clicking on the link takes you to the Asset Graph View.
diff --git a/airflow-ctl/docs/cli-and-env-variables-ref.rst
b/airflow-ctl/docs/cli-and-env-variables-ref.rst
index dd60bfd5323..0df55ae9f12 100644
--- a/airflow-ctl/docs/cli-and-env-variables-ref.rst
+++ b/airflow-ctl/docs/cli-and-env-variables-ref.rst
@@ -44,7 +44,7 @@ Environment Variables
The token used to authenticate with the Airflow API. This is only
required if you are using the Airflow API and have not set up
- authentication using a different method. If username and password hasn't
been used.
+ authentication using a different method, such as a username and password.
.. envvar:: AIRFLOW_CLI_ENVIRONMENT
diff --git a/airflow-ctl/docs/howto/index.rst b/airflow-ctl/docs/howto/index.rst
index 92f92443215..a8efd3a602e 100644
--- a/airflow-ctl/docs/howto/index.rst
+++ b/airflow-ctl/docs/howto/index.rst
@@ -93,7 +93,7 @@ The token can be acquired from the Airflow API or generated
using a username and
Parameter Details for airflowctl auth login
```````````````````````````````````````````
-**--api-url**: This parameter is required. (e.g. ``http://localhost:8080``)
+**--api-url**: This parameter is optional. (e.g. ``http://localhost:8080``)
The default value is ``http://localhost:8080``. Full URL of the Airflow API.
Without any ``/api/*`` suffixes.
If you are running the ``airflowctl`` in ``breeze`` container, it is optional.
@@ -101,7 +101,7 @@ If you are running the ``airflowctl`` in ``breeze``
container, it is optional.
If you are setting the token via the environment variable
``AIRFLOW_CLI_TOKEN``, you can skip using this parameter.
**--username**: This parameter is optional.
-If you are not using ``--api-token`` or the environment variable
``AIRFLOW_CLI_TOKEN``, you must provide a username to authentication along with
``--password``.
+If you are not using ``--api-token`` or the environment variable
``AIRFLOW_CLI_TOKEN``, you must provide a username to authenticate along with
``--password``.
**--password**: This parameter is optional.
If you provide a username via ``--username`` this is the required password to
authenticate.
diff --git a/airflow-ctl/docs/installation/index.rst
b/airflow-ctl/docs/installation/index.rst
index d3f2062c297..97170bb00b7 100644
--- a/airflow-ctl/docs/installation/index.rst
+++ b/airflow-ctl/docs/installation/index.rst
@@ -30,7 +30,7 @@ Installation of airflowctl
Installing from sources <installing-from-sources>
Installing from PyPI <installing-from-pypi>
-This page describes installations options that you might use when considering
how to install Airflow®.
+This page describes installation options that you might use when considering
how to install Airflow®.
Airflow consists of many components, often distributed among many physical or
virtual machines, therefore
installation of Airflow might be quite complex, depending on the options you
choose.
diff --git a/airflow-ctl/docs/installation/installing-from-sources.rst
b/airflow-ctl/docs/installation/installing-from-sources.rst
index ebf02712350..43ba3e5e368 100644
--- a/airflow-ctl/docs/installation/installing-from-sources.rst
+++ b/airflow-ctl/docs/installation/installing-from-sources.rst
@@ -29,14 +29,14 @@ Released packages
the top-left of the page.
The Source packages are official packages of the Apache Software Foundation -
and the ones that you can
-use is you want to build the packages yourself from the source code and be
sure that the provenance of
+use if you want to build the packages yourself from the source code and be
sure that the provenance of
the packages is verified and matches the source code from the repository and
you can verify the
checksums and signatures of the packages.
-The ``sdist`` and ``whl`` packages released are the convenience packages - of
installation also installed from
+The ``sdist`` and ``whl`` packages released are the convenience packages - for
installation, also built from
the same sources and you can still verify the origin of the packages and want
to verify checksums and
-signatures of the packages. The packages are available via the Official Apache
Software Foundations Downloads
-`Official Apache Software Foundations Downloads <https://dlcdn.apache.org/>`_
+signatures of the packages. The packages are available via the
+`Official Apache Software Foundation Downloads <https://dlcdn.apache.org/>`_
The ``|version|`` downloads of Airflow Ctl are available at:
@@ -47,7 +47,7 @@ The ``|version|`` downloads of Airflow Ctl are available at:
* `Whl package for airflow-ctl distribution <{{ closer_lua_url
}}/apache_airflow_ctl-{{ airflowctl_version }}-py3-none-any.whl>`__ (`asc <{{
base_url }}/apache_airflow_ctl-{{ airflowctl_version
}}-py3-none-any.whl.asc>`__, `sha512 <{{ base_url }}/apache_airflow_ctl-{{
airflowctl_version }}-py3-none-any.whl.sha512>`__)
If you want to install from the source code, you can download from the sources
link above, it will contain
-a ``INSTALL`` file containing details on how you can build and install
airflowctl.
+an ``INSTALL`` file containing details on how you can build and install
airflowctl.
Release integrity
'''''''''''''''''
@@ -92,7 +92,7 @@ or
.. code-block:: bash
- pgp apache-airflow-********.asc
+ pgp apache-airflow-ctl-********.asc
Example:
@@ -118,7 +118,7 @@ For SHA512 sum check, download the relevant ``sha512`` and
run the following:
.. code-block:: bash
- shasum -a 512 apache-airflow-ctl--******** | diff -
apache-airflow-ctl--********.sha512
+ shasum -a 512 apache-airflow-ctl-******** | diff -
apache-airflow-ctl-********.sha512
The ``SHASUM`` of the file should match the one provided in ``.sha512`` file.
diff --git a/airflow-ctl/docs/installation/prerequisites.rst
b/airflow-ctl/docs/installation/prerequisites.rst
index 9d2efa3641c..4777b662476 100644
--- a/airflow-ctl/docs/installation/prerequisites.rst
+++ b/airflow-ctl/docs/installation/prerequisites.rst
@@ -18,10 +18,7 @@
Prerequisites
-------------
-airflowctl is tested with:
-
-
-The minimum memory required we recommend airflowctl to run with is 200MB, but
the actual requirements depend
+The minimum memory we recommend for airflowctl to run with is 200MB, but the
actual requirements depend
wildly on the deployment options you have.
The Keyring backend needs to be installed separately into your operating
system. This will enhance security. See :doc:`/security` for more information.
diff --git a/chart/docs/extending-the-chart.rst
b/chart/docs/extending-the-chart.rst
index e368e019c20..172dbb59acc 100644
--- a/chart/docs/extending-the-chart.rst
+++ b/chart/docs/extending-the-chart.rst
@@ -28,7 +28,7 @@ You can extend the official Airflow chart by applying the
following steps.
Create your custom Helm Chart
-----------------------------
-First, you will need to create you own chart directory. You can do it by
running the following command:
+First, you will need to create your own chart directory. You can do it by
running the following command:
.. code-block:: bash
diff --git a/chart/docs/manage-dag-files.rst b/chart/docs/manage-dag-files.rst
index d4fb3eb08cd..94e08ed13a5 100644
--- a/chart/docs/manage-dag-files.rst
+++ b/chart/docs/manage-dag-files.rst
@@ -214,7 +214,7 @@ To configure mounting Dags from private GitHub repository,
follow below steps:
ssh-keygen -t rsa -b 4096 -C "[email protected]"
3. Add the public key to your private repo under ``Settings > Deploy keys``.
-4. Convert the private ssh key to a base64 string and save it's value.
+4. Convert the private ssh key to a base64 string and save its value.
.. note::
diff --git a/chart/docs/parameters-ref.rst b/chart/docs/parameters-ref.rst
index e460515f0fc..78955c10a96 100644
--- a/chart/docs/parameters-ref.rst
+++ b/chart/docs/parameters-ref.rst
@@ -81,7 +81,7 @@ and install the chart:
Deprecated Parameters
=====================
-The following table contains all deprecated configuration parameters of the
Airflow chart with their default values. All values defined in below table with
be removed
+The following table contains all deprecated configuration parameters of the
Airflow chart with their default values. All values defined in below table will
be removed
in the next Helm Chart major release.
.. jinja:: params_ctx
diff --git a/chart/docs/production-guide.rst b/chart/docs/production-guide.rst
index 029a71e7478..9d5fcd88533 100644
--- a/chart/docs/production-guide.rst
+++ b/chart/docs/production-guide.rst
@@ -49,7 +49,7 @@ To provide the database credentials to Airflow, you have 2
options - in your val
Values file
^^^^^^^^^^^
-This is the simpler options, as the chart will create a Kubernetes Secret for
you. However, keep in mind your credentials will be in your values file.
+This is the simpler option, as the chart will create a Kubernetes Secret for
you. However, keep in mind your credentials will be in your values file.
.. code-block:: yaml
:caption: values.yaml
@@ -128,8 +128,8 @@ If you are using PostgreSQL as your database, you will
likely want to enable `Pg
Due to distributed nature of Airflow, it can open a lot of database
connections. Using a connection pooler can significantly
reduce the number of open connections on the database.
-Database credentials stored Values file
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Database credentials stored in Values file
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
.. code-block:: yaml
:caption: values.yaml
@@ -138,8 +138,8 @@ Database credentials stored Values file
enabled: true
-Database credentials stored Kubernetes Secret
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+Database credentials stored in Kubernetes Secret
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The default connection string in this case will not work. You need to modify
accordingly the Kubernetes secret:
@@ -633,7 +633,7 @@ Security Context
Constraints
^^^^^^^^^^^
-A ``Security Context Constraint`` (SCC) is a OpenShift construct that works as
a RBAC rule. However, it targets Pods instead of users.
+A ``Security Context Constraint`` (SCC) is an OpenShift construct that works
as an RBAC rule. However, it targets Pods instead of users.
When defining a SCC, one can control actions and resources a POD can perform
or access during startup and runtime.
The SCCs are split into different levels or categories with the ``restricted``
SCC being the default one assigned to Pods.
diff --git a/chart/docs/setting-resources-for-containers.rst
b/chart/docs/setting-resources-for-containers.rst
index 397d032052c..7c1398c62a4 100644
--- a/chart/docs/setting-resources-for-containers.rst
+++ b/chart/docs/setting-resources-for-containers.rst
@@ -50,4 +50,4 @@ For example, specifying resources for scheduler container:
memory: 1Gi
requests:
cpu: 500m
- memory: 512Gi
+ memory: 512Mi
diff --git a/task-sdk/docs/deferred-vs-async-operators.rst
b/task-sdk/docs/deferred-vs-async-operators.rst
index a2a0df16054..9d1e1f00579 100644
--- a/task-sdk/docs/deferred-vs-async-operators.rst
+++ b/task-sdk/docs/deferred-vs-async-operators.rst
@@ -65,7 +65,7 @@ When to Use Deferred Operators
Prefer a deferred operator when:
- There is an existing deferrable operator that covers your use case (e.g.,
HttpOperator deferrable mode).
-- The task waits for a single or limited external events.
+- The task waits for a single external event or a limited number of events.
- You want to free worker resources while waiting for triggers.
- You don't need to loop over the same operator multiple times (e.g.
multiplexing).
diff --git a/task-sdk/docs/examples.rst b/task-sdk/docs/examples.rst
index 727c15b3e5f..a3115d79a90 100644
--- a/task-sdk/docs/examples.rst
+++ b/task-sdk/docs/examples.rst
@@ -100,7 +100,7 @@ TaskFlow API Tutorial
---------------------
This section provides a concise, code-first view. For the full tutorial and
context,
-see the `core TaskFlow tutorial
<../../airflow-core/docs/tutorial/taskflow.rst>`_.
+see the :doc:`core TaskFlow tutorial <apache-airflow:tutorial/taskflow>`.
Step 1: Define the Dag
----------------------
diff --git a/task-sdk/docs/executable-bundle-spec.rst
b/task-sdk/docs/executable-bundle-spec.rst
index 281e398cb14..856aeca94e9 100644
--- a/task-sdk/docs/executable-bundle-spec.rst
+++ b/task-sdk/docs/executable-bundle-spec.rst
@@ -78,6 +78,7 @@ for SDK users. Go SDK's ``airflow-go-pack`` is a good example.
#!/usr/bin/env python3
import hashlib
+ import pathlib
import shutil
import struct
