This is an automated email from the ASF dual-hosted git repository.
kaxil pushed a commit to branch commonai-approval-walkthrough
in repository https://gitbox.apache.org/repos/asf/airflow.git
The following commit(s) were added to refs/heads/commonai-approval-walkthrough
by this push:
new e3fc608bda4 Re-wrap the version and notifier paragraphs on the
approval page
e3fc608bda4 is described below
commit e3fc608bda42ff9f02242e211dfe13c1c2ee1053
Author: Kaxil Naik <[email protected]>
AuthorDate: Thu Oct 15 13:56:01 2026 +0100
Re-wrap the version and notifier paragraphs on the approval page
---
providers/common/ai/docs/approval_gates.rst | 16 +++++++++-------
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/providers/common/ai/docs/approval_gates.rst
b/providers/common/ai/docs/approval_gates.rst
index be0919dfa4f..a9907e1909b 100644
--- a/providers/common/ai/docs/approval_gates.rst
+++ b/providers/common/ai/docs/approval_gates.rst
@@ -29,10 +29,10 @@ reads the output in the Airflow UI and approves it, edits
it, or rejects it, and
approved answer reaches the tasks downstream. To review each tool call an
agent makes
rather than its final answer, see :doc:`tool_approval`.
-Approval gates need Airflow 3.1 or later. On an older Airflow version the
-operator raises ``AirflowOptionalProviderFeatureException:
require_approval=True needs Airflow 3.1+.``
-when it is constructed, so the Dag file
-fails to import, and with it every Dag defined in that file. A dynamically
mapped
+Approval gates need Airflow 3.1 or later. On an older Airflow version the
operator
+raises ``AirflowOptionalProviderFeatureException: require_approval=True needs
Airflow 3.1+.``
+when it is constructed, so the Dag file fails to import, and with it every Dag
+defined in that file. A dynamically mapped
task (``.expand()``) is only constructed when it runs, so there the same error
surfaces as a task failure, before the model is called.
@@ -218,9 +218,11 @@ the review ``{{ task.subject }}`` and ``{{ task.body }}``
in their templates,
as the example under `Timeouts`_ does: its notifier writes the subject and
body to the
task log, just before ``Pausing task as AWAITING_INPUT.`` The ``@task.llm``
decorator
and the ``LLMOperator`` subclasses (``LLMBranchOperator``,
``LLMSQLQueryOperator``,
-``LLMSchemaCompareOperator``, ``LLMFileAnalysisOperator``) accept the same
parameter. A notifier that raises is logged as
-``Approval notifier <notifier> failed; the review stays open`` and the task
still waits for
-the review; a Jinja ``TemplateError`` in a notifier's template fails the task.
A retry re-runs the LLM and re-notifies with the regenerated output; what the
+``LLMSchemaCompareOperator``, ``LLMFileAnalysisOperator``) accept the same
+parameter. A notifier that raises is logged as
+``Approval notifier <notifier> failed; the review stays open`` and the task
still
+waits for the review. A Jinja ``TemplateError`` in a notifier's template
fails the
+task. A retry re-runs the LLM and re-notifies with the regenerated output.
What the
reopened review shows depends on the Airflow version, as described under
`What each answer does`_.