apache-airflow-task-sdk 1.3.2rc1__tar.gz → 1.4.0b2__tar.gz

{apache_airflow_task_sdk-1.3.2rc1 → apache_airflow_task_sdk-1.4.0b2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.5
 Name: apache-airflow-task-sdk
-Version: 1.3.2rc1
+Version: 1.4.0b2
 Summary: Python Task SDK for Apache Airflow DAG Authors
 Project-URL: Bug Tracker, https://github.com/apache/airflow/issues
 Project-URL: Documentation, https://airflow.staged.apache.org/docs/
@@ -22,22 +22,22 @@ Classifier: Environment :: Web Environment
 Classifier: Framework :: Apache Airflow
 Classifier: Intended Audience :: Developers
 Classifier: Intended Audience :: System Administrators
-Classifier: Programming Language :: Python :: 3.10
 Classifier: Programming Language :: Python :: 3.11
 Classifier: Programming Language :: Python :: 3.12
 Classifier: Programming Language :: Python :: 3.13
 Classifier: Programming Language :: Python :: 3.14
 Classifier: Topic :: System :: Monitoring
-Requires-Python: !=3.15,>=3.10
-Requires-Dist: apache-airflow-core<3.4.0,>=3.3.0rc1
+Requires-Python: !=3.15,>=3.11
+Requires-Dist: apache-airflow-core<3.5.0,>=3.4.0b1
 Requires-Dist: asgiref>=2.3.0; python_version < '3.14'
 Requires-Dist: asgiref>=3.11.1; python_version >= '3.14'
 Requires-Dist: attrs!=25.2.0,>=24.2.0
 Requires-Dist: babel>=2.17.0
+Requires-Dist: cadwyn>=6.1.1
 Requires-Dist: colorlog>=6.8.2
 Requires-Dist: fsspec>=2023.10.0
 Requires-Dist: greenback>=1.2.1
-Requires-Dist: httpx>=0.27.0
+Requires-Dist: httpx2>=2.0.0
 Requires-Dist: importlib-metadata>=6.5; python_version < '3.12'
 Requires-Dist: isoduration>=20.11.0
 Requires-Dist: jinja2>=3.1.5
@@ -53,8 +53,10 @@ Requires-Dist: psutil>=6.1.0
 Requires-Dist: pydantic>2.11.0
 Requires-Dist: pygtrie>=2.5.0
 Requires-Dist: python-dateutil>=2.7.0
+Requires-Dist: pyyaml>=6.0.3
 Requires-Dist: structlog>=26.1.0
 Requires-Dist: tenacity>=8.3.0
+Requires-Dist: truststore>=0.10.0
 Requires-Dist: typing-extensions>=4.14.1
 Provides-Extra: all
 Requires-Dist: datadog>=0.50.0; extra == 'all'

{apache_airflow_task_sdk-1.3.2rc1 → apache_airflow_task_sdk-1.4.0b2}/dev/generate_task_sdk_models.py

@@ -20,8 +20,9 @@ import json
 import os
 import sys
 from pathlib import Path
+from tomllib import load as load_tomllib
 
-import httpx
+import httpx2
 from datamodel_code_generator import (
     DataModelType,
     DatetimeClassType,
@@ -47,11 +48,6 @@ task_sdk_root = Path(__file__).parents[1]
 
 
 def load_config():
-    try:
-        from tomllib import load as load_tomllib
-    except ImportError:
-        from tomli import load as load_tomllib
-
     pyproject = AIRFLOW_TASK_SDK_ROOT_PATH / "pyproject.toml"
     # Simulate what `datamodel-code-generator` does on the CLI
     with pyproject.open("rb") as fh:
@@ -81,7 +77,7 @@ def generate_file():
     app = InProcessExecutionAPI()
 
     latest_version = app.app.versions.version_values[0]
-    client = httpx.Client(transport=app.transport)
+    client = httpx2.Client(transport=app.transport)
     openapi_schema = (
         client.get(f"http://localhost/openapi.json?version={latest_version}").raise_for_status().text
     )

{apache_airflow_task_sdk-1.3.2rc1 → apache_airflow_task_sdk-1.4.0b2}/docs/airflow-metadata.schema.json

@@ -4,7 +4,7 @@
   "title": "Airflow Executable SDK Bundle Metadata",
   "description": "Build-time manifest declaring DAG and task identifiers exposed by an Airflow native-executable SDK bundle. See the Executable Bundle Spec documentation in the Airflow Task SDK.",
   "type": "object",
-  "required": ["airflow_bundle_metadata_version", "sdk", "source", "dags"],
+  "required": ["airflow_bundle_metadata_version", "sdk", "dags"],
   "additionalProperties": true,
   "properties": {
     "airflow_bundle_metadata_version": {
@@ -35,21 +35,63 @@
         }
       }
     },
-    "source": {
+    "entrypoint_path": {
       "type": "string",
-      "description": "Original filename of the primary DAG source file (e.g. 'example.go'). The file's bytes are embedded in the bundle's source region; this field is a display name used by the Airflow UI.",
+      "description": "Path of the entrypoint source file (e.g. 'example/bundle/main.go'). It must be one of the sources paths. Shown for a Dag that dag_source_paths does not map.",
       "minLength": 1
     },
+    "dag_source_paths": {
+      "type": "object",
+      "description": "Mapping of dag_id to the path of the file that defines the Dag. Every value must be one of the sources paths.",
+      "additionalProperties": {
+        "type": "string",
+        "minLength": 1
+      }
+    },
+    "sources": {
+      "type": "array",
+      "description": "The embedded source files, in the order they appear in the source region. A bundle without it embeds no source. Paths must be unique.",
+      "items": {
+        "$ref": "#/$defs/sourceEntry"
+      }
+    },
     "dags": {
       "type": "object",
-      "description": "Mapping of dag_id to DAG entry. Every dag_id the bundle exposes must appear here.",
-      "minProperties": 1,
+      "description": "Mapping of dag_id to the tasks the bundle runs for a Python Dag with stub TaskHandler. May be empty, for example when the bundle only declares Dag definitions.",
       "additionalProperties": {
         "$ref": "#/$defs/dagEntry"
       }
     }
   },
   "$defs": {
+    "sourceEntry": {
+      "type": "object",
+      "description": "One embedded source file inside the bundle's source region.",
+      "required": ["path", "offset", "length", "sha256"],
+      "additionalProperties": true,
+      "properties": {
+        "path": {
+          "type": "string",
+          "description": "The file's path as the author knows it (e.g. 'example/bundle/main.go').",
+          "minLength": 1
+        },
+        "offset": {
+          "type": "integer",
+          "description": "The file's start, in bytes from the start of the source region.",
+          "minimum": 0
+        },
+        "length": {
+          "type": "integer",
+          "description": "The file's length in bytes.",
+          "minimum": 0
+        },
+        "sha256": {
+          "type": "string",
+          "description": "Lower-case hexadecimal SHA-256 of the file's bytes.",
+          "pattern": "^[0-9a-f]{64}$"
+        }
+      }
+    },
     "dagEntry": {
       "type": "object",
       "description": "Static description of a single DAG declared in the bundle.",

{apache_airflow_task_sdk-1.3.2rc1 → apache_airflow_task_sdk-1.4.0b2}/docs/api.rst

@@ -94,6 +94,8 @@ Bases
 
 .. autoapiclass:: airflow.sdk.BaseXCom
 
+.. autoapiclass:: airflow.sdk.bases.xcom.XComCoordinate
+
 .. autoapiclass:: airflow.sdk.BranchMixIn
 
 .. autoapiclass:: airflow.sdk.PokeReturnValue
@@ -130,6 +132,8 @@ Tasks & Operators
 -----------------
 .. autoapiclass:: airflow.sdk.TaskGroup
 
+.. autoapiclass:: airflow.sdk.LoopDecision
+
 .. autoclass:: airflow.sdk.TaskInstance
 
 .. autoapiclass:: airflow.sdk.XComArg
@@ -156,6 +160,8 @@ Tasks page in the core docs for usage and design rationale.
 
 .. autoapiclass:: airflow.sdk.ExceptionRetryPolicy
 
+.. autoapiclass:: airflow.sdk.ChainRetryPolicy
+
 .. autoapiclass:: airflow.sdk.RetryRule
 
 .. autoapiclass:: airflow.sdk.RetryDecision
@@ -202,8 +208,12 @@ Assets
 
 Timetables
 ----------
+.. autoapiclass:: airflow.sdk.AssetAndTimeSchedule
+
 .. autoapiclass:: airflow.sdk.AssetOrTimeSchedule
 
+.. autoapiclass:: airflow.sdk.AssetTriggeredTimetable
+
 .. autoapiclass:: airflow.sdk.CronDataIntervalTimetable
 
 .. autoapiclass:: airflow.sdk.CronTriggerTimetable
@@ -302,6 +312,45 @@ See :doc:`apache-airflow:authoring-and-scheduling/language-sdks/index` for a con
 
 .. autoapiclass:: airflow.sdk.coordinators.executable.ExecutableCoordinator
 
+.. rubric:: Node.js (TypeScript)
+
+.. autoapiclass:: airflow.sdk.coordinators.node.NodeCoordinator
+
+Dag Importers
+-------------
+
+|experimental|
+
+Dag importers turn the contents of a Dag bundle into Dags. This interface may still change in a minor
+release while it is being stabilized. See :doc:`apache-airflow:administration-and-deployment/dag-importers` for how
+importers are configured and how to write one.
+
+.. autoapiclass:: airflow.sdk.importers.AbstractDagImporter
+
+.. autoapiclass:: airflow.sdk.importers.DagDefinition
+
+.. autoapiclass:: airflow.sdk.importers.FileDagDefinition
+
+.. autoapiclass:: airflow.sdk.importers.FilesystemDagDefinition
+
+.. autoapiclass:: airflow.sdk.importers.DagImportResult
+
+.. autoapiclass:: airflow.sdk.importers.DagImportError
+
+.. autoapiclass:: airflow.sdk.importers.DagImportWarning
+
+.. autoapiclass:: airflow.sdk.importers.DagSourceCode
+
+.. autoapifunction:: airflow.sdk.importers.find_file_dag_definitions
+
+.. autoapifunction:: airflow.sdk.importers.get_file_suffix
+
+.. rubric:: Built-in importers
+
+.. autoapiclass:: airflow.sdk.importers.PythonDagImporter
+
+.. autoapiclass:: airflow.sdk.importers.ZipImporter
+
 Execution Time Components
 -------------------------
 .. rubric:: Context

{apache_airflow_task_sdk-1.3.2rc1 → apache_airflow_task_sdk-1.4.0b2}/docs/concepts.rst

@@ -45,7 +45,7 @@ Understanding the task lifecycle helps Dag authors write more effective tasks an
   - ``task_reschedule_count``: Number of times this task has been rescheduled
   - ``variables``: List of Airflow variables accessible to the task instance
   - ``connections``: List of Airflow connections accessible to the task instance
-  - ``upstream_map_indexes``: Mapping of upstream task IDs to their map indexes for dynamic task mapping scenarios
+  - ``upstream_map_indexes``: Mapping of upstream task IDs to their map indexes for task mapping scenarios
   - ``next_method``: Method name to call when resuming from a deferred state (set when task resumes from a trigger)
   - ``next_kwargs``: Arguments to pass to the ``next_method`` (can be encrypted for sensitive data)
   - ``xcom_keys_to_clear``: List of XCom keys that need to be cleared and purged by the worker

{apache_airflow_task_sdk-1.3.2rc1 → apache_airflow_task_sdk-1.4.0b2}/docs/conf.py

@@ -57,7 +57,8 @@ extensions = [
     "sphinx.ext.intersphinx",
     "airflow_intersphinx",
     "exampleinclude",
-    "sphinxcontrib.spelling",
+    "mermaid_svg",
+    "airflow_spelling",
 ]
 
 autoapi_dirs = [CONF_DIR.joinpath("..", "src").resolve()]

{apache_airflow_task_sdk-1.3.2rc1 → apache_airflow_task_sdk-1.4.0b2}/docs/deferred-vs-async-operators.rst

@@ -38,7 +38,7 @@ Deferred Operators
 ------------------
 
 A deferred operator is an operator that can pause its execution until an external trigger event occurs,
-without holding a worker slot. For more details see :doc:`airflow:authoring-and-scheduling/deferring`.
+without holding a worker slot. For more details see :doc:`apache-airflow:authoring-and-scheduling/deferring`.
 Examples include the HttpOperator in deferrable mode, sensors or operators integrated with triggers.
 
 Key characteristics:
@@ -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).
 
@@ -265,17 +265,17 @@ it is equally important to understand scenarios where one may **not** be appropr
   If your workflow is better suited for deferring but no operator exists yet,
   consider implementing a custom deferred operator rather than defaulting to async.
 
-Comparison with Dynamic Task Mapping
-------------------------------------
+Comparison with task mapping
+----------------------------
 
-Async operators and Dynamic Task Mapping solve different problems and have different trade-offs.
+Async operators and task mapping solve different problems and have different trade-offs.
 
 .. list-table::
    :header-rows: 1
 
    * - Aspect
      - Async ``@task``
-     - Dynamic Task Mapping (deferrable)
+     - Task mapping (deferrable)
    * - Worker slots
      - 1 worker slot (shared event loop)
      - N worker slots (one per mapped task instance)
@@ -292,5 +292,5 @@ Async operators and Dynamic Task Mapping solve different problems and have diffe
      - Minimal
      - Scheduler must manage N task instances
 
-For more details about Dynamic Task Mapping, see the
-:ref:`dynamic task mapping <sdk-dynamic-task-mapping>` page.
+For more details about task mapping, see the
+:ref:`task mapping <sdk-dynamic-task-mapping>` page.

{apache_airflow_task_sdk-1.3.2rc1 → apache_airflow_task_sdk-1.4.0b2}/docs/dynamic-task-mapping.rst

@@ -17,10 +17,10 @@
 
 .. _sdk-dynamic-task-mapping:
 
-Dynamic Task Mapping with Task SDK
-==================================
+Mapped tasks with Task SDK
+==========================
 
-Dynamic Task Mapping allows tasks defined with the Task SDK to generate
+Task mapping, also called dynamic task mapping, allows tasks defined with the Task SDK to generate
 a variable number of task instances at runtime based on upstream data.
 This is enabled via the ``expand()`` method on tasks, providing a way
 to parallelize execution without knowing the number of tasks ahead of time.
@@ -96,4 +96,4 @@ For advanced patterns—such as repeated mapping, cross-product mapping,
 named mappings (via ``map_index_template``), and handling large
 datasets—see the Airflow Core documentation:
 
-`Dynamic Task Mapping in the Airflow Core docs <https://airflow.apache.org/docs/apache-airflow/stable/authoring-and-scheduling/dynamic-task-mapping.html>`_.
+`Mapped tasks in the Airflow Core docs <https://airflow.apache.org/docs/apache-airflow/stable/authoring-and-scheduling/dynamic-task-mapping.html>`_.

{apache_airflow_task_sdk-1.3.2rc1 → apache_airflow_task_sdk-1.4.0b2}/docs/examples.rst

@@ -63,13 +63,13 @@ Tasks and Operators
 
 Example: Defining tasks and using operators
 
-Use the :func:`airflow.sdk.task` decorator to wrap Python callables as tasks and leverage dynamic task mapping with the ``.expand()`` method. Tasks communicate via :class:`airflow.sdk.XComArg`. For traditional operators and sensors, import classes like :class:`airflow.sdk.BaseOperator` or :class:`airflow.sdk.Sensor`.
+Use the :func:`airflow.sdk.task` decorator to wrap Python callables as tasks and leverage task mapping with the ``.expand()`` method. Tasks communicate via :class:`airflow.sdk.XComArg`. For traditional operators and sensors, import classes like :class:`airflow.sdk.BaseOperator` or :class:`airflow.sdk.Sensor`.
 
 .. exampleinclude:: ../../airflow-core/src/airflow/example_dags/example_dynamic_task_mapping.py
    :language: python
    :start-after: [START example_dynamic_task_mapping]
    :end-before: [END example_dynamic_task_mapping]
-   :caption: Dynamic task mapping with ``expand()``
+   :caption: Task mapping with ``expand()``
 
 .. exampleinclude:: ../../airflow-core/src/airflow/example_dags/example_xcomargs.py
    :language: python
@@ -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
 ----------------------

{apache_airflow_task_sdk-1.3.2rc1 → apache_airflow_task_sdk-1.4.0b2}/docs/executable-bundle-spec.rst

@@ -42,29 +42,37 @@ A bundle file therefore has three regions, in order from offset 0:
 
 1. The native executable (ELF / Mach-O / PE), including any code-signing
    structures the platform appends.
-2. The primary DAG source file, embedded verbatim (UTF-8). MAY have length 0.
+2. The embedded source files, each verbatim (UTF-8), back to back. MAY have length 0.
+   The metadata indexes them. See :ref:`the source region <bundle-source-region>`.
 3. The build-time manifest (``airflow-metadata.yaml`` content, UTF-8).
 
 The file ends with a fixed 64-byte trailer that locates regions (2) and (3),
 carries an integrity hash of the binary region, and identifies the file as a
 bundle. See :ref:`bundle-trailer-layout`.
 
-Filenames follow OS conventions for executables: no extension on Linux/macOS,
-``.exe`` on Windows. The scanner identifies bundles by the trailer's magic,
-not by the filename.
+A bundle file has no file extension, and the Dag processor does not treat a
+file with an extension as a bundle. The scanner identifies bundles by the
+trailer's magic.
 
 The complete bundle file regions are:
 
 .. code-block:: text
 
     [0,            source_start)    native binary (must be non-empty)
-    [source_start, metadata_start)  embedded source (may be zero length)
+    [source_start, metadata_start)  embedded source files (may be zero length)
     [metadata_start, file_size-64)  build-time manifest
     [file_size-64, file_size)       64-byte trailer
 
 where ``metadata_start = file_size - 64 - metadata_len`` and
 ``source_start = metadata_start - source_len``.
 
+.. _bundle-source-region:
+
+The source region holds the source files of the Dags the bundle defines, one entry per file. Files
+are concatenated with no separator, and the ``sources`` list in the manifest gives each file's
+``path``, ``offset`` and ``length`` within the region and its ``sha256``. A file's ``offset`` is
+relative to ``source_start``, so the first file has offset ``0``.
+
 Reference Implementation
 ------------------------
 
@@ -78,12 +86,13 @@ 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
 
     BINARY = pathlib.Path(...)  # Path to the compiled executable.
     OUTPUT = pathlib.Path(...)  # Where to put the processed executable.
-    SOURCE = b"..."  # Source code to embed.
+    SOURCES = [b"..."]  # Source files to embed, in the order the manifest lists them.
     METADATA = b"..."  # UTF-8-encoded YAML metadata.
 
     # SHA-256 covers the binary region only: bytes [0, source_start).
@@ -91,7 +100,7 @@ for SDK users. Go SDK's ``airflow-go-pack`` is a good example.
 
     trailer = struct.pack(
         "<III 32s 12s 8s",
-        len(SOURCE),  # source_len
+        sum(map(len, SOURCES)),  # source_len
         len(METADATA),  # metadata_len
         1,  # footer_ver
         binary_sha256,
@@ -102,7 +111,7 @@ for SDK users. Go SDK's ``airflow-go-pack`` is a good example.
 
     shutil.copy(BINARY, OUTPUT)
     with OUTPUT.open("ab") as fh:
-        fh.write(SOURCE)  # Embedded source region.
+        fh.writelines(SOURCES)  # Embedded source region.
         fh.write(METADATA)  # Metadata region.
         fh.write(trailer)
     OUTPUT.chmod(0o755)
@@ -155,9 +164,17 @@ Reader algorithm:
    re-hash on every exec; a cache miss (file replaced, mtime bumped)
    triggers re-verification.
 7. Read ``metadata_len`` bytes from ``metadata_start`` for the manifest.
-8. Read ``source_len`` bytes from ``source_start`` for the source view.
-   If ``source_len == 0``, no source is embedded; the UI displays
-   "(source not available)".
+8. Read the source files through the manifest's ``sources`` list. For each entry, check that
+   ``offset`` and ``length`` are non-negative integers and that ``offset + length <= source_len``.
+   To read a file, read ``length`` bytes from ``source_start + offset`` and compare their SHA-256 to
+   ``sha256``. A duplicate ``path`` or a digest mismatch is an error. Without a ``sources`` key, no
+   source is embedded, and the UI shows a notice in place of the source.
+
+   A Dag's source file is the ``dag_source_paths`` entry for its ``dag_id``. A Dag with no entry,
+   such as one built dynamically, shows ``entrypoint_path``. A Dag owned by another language, such as
+   the Python Dag that a bundle's task handlers run for, shows its own source and not an embedded
+   file. ``entrypoint_path`` and every ``dag_source_paths`` value MUST be one of the ``sources``
+   paths.
 
 Source comes *before* metadata so a future ``footer_ver`` MAY introduce
 additional trailing blobs (e.g. signed checksums, compressed deps) by
@@ -181,7 +198,19 @@ and editors.
       language: go
       version: "0.1.0"
       supervisor_schema_version: "2026-06-16"
-    source: example.go
+    entrypoint_path: example/bundle/main.go
+    dag_source_paths:
+      example_dag: example/bundle/main.go
+      another_dag: example/bundle/dags/another.go
+    sources:
+      - path: example/bundle/main.go
+        offset: 0
+        length: 1532
+        sha256: 0f3a...e91c
+      - path: example/bundle/dags/another.go
+        offset: 1532
+        length: 811
+        sha256: 7b21...04d8
     dags:
       example_dag:
         tasks:
@@ -213,17 +242,30 @@ Top-level keys:
       task-execution time, and an unknown version causes that bundle to be
       skipped.
 
-``source`` (string, required)
-    Original filename of the primary DAG source file (e.g. ``example.go``).
-    The file's bytes live in the source region of the bundle, not at this
-    path; this field is a display name the Airflow UI uses to label the
-    source-view panel and pick a syntax-highlighting mode from the
-    extension.
+``entrypoint_path`` (string, optional)
+    Path of the entrypoint source file, such as the Go ``main`` package file. It MUST be one of
+    the ``sources`` paths. The Airflow UI shows it for a Dag that ``dag_source_paths`` does not map.
+
+``dag_source_paths`` (mapping, optional)
+    Mapping of ``dag_id`` to the path of the file that defines the Dag. Every value MUST be one of
+    the ``sources`` paths.
+
+``sources`` (list, optional)
+    The embedded source files, in the order they appear in the source region. A bundle without it
+    embeds no source. Each entry has:
+
+    - ``path`` (string, required): the file's path as the author knows it, such as
+      ``example/bundle/main.go``. Paths MUST be unique. The Airflow UI picks a syntax-highlighting
+      mode from the extension.
+    - ``offset`` (integer, required): the file's start, in bytes from ``source_start``.
+    - ``length`` (integer, required): the file's length in bytes.
+    - ``sha256`` (string, required): the lower-case hexadecimal SHA-256 of the file's bytes.
 
 ``dags`` (mapping, required)
-    Mapping of ``dag_id`` to a *DAG entry*. Every ``dag_id`` the bundle
-    exposes MUST appear here. The scanner uses these keys to match a DAG
-    parsing or task-execution request to the bundle that owns it.
+    Mapping of ``dag_id`` to a *DAG entry*, for each Python Dag with stub TaskHandler whose tasks the
+    bundle runs. The scanner uses these keys to match a task-execution request to the bundle that
+    owns it. The mapping MAY be empty, for example when the bundle only declares Dag definitions,
+    because the Dag processor finds those by running the binary.
 
 DAG entry fields:
 
@@ -242,16 +284,16 @@ Go bundle::
 
     example
     ├── ELF/Mach-O/PE executable
-    ├── source region:   contents of example.go
-    ├── metadata region: airflow-metadata.yaml (source: example.go)
+    ├── source region:   example/bundle/main.go, example/bundle/dags/another.go
+    ├── metadata region: airflow-metadata.yaml (entrypoint_path, dag_source_paths, sources)
     └── trailer (64 B):  lengths + binary_sha256 + AFBNDL01 magic
 
 Rust bundle::
 
     pipeline
     ├── ELF/Mach-O/PE executable
-    ├── source region:   contents of main.rs
-    ├── metadata region: airflow-metadata.yaml (source: main.rs)
+    ├── source region:   src/main.rs
+    ├── metadata region: airflow-metadata.yaml (entrypoint_path: src/main.rs)
     └── trailer (64 B):  lengths + binary_sha256 + AFBNDL01 magic
 
 The bundle is one file. ``./example`` runs the binary; the appended data
@@ -271,7 +313,7 @@ that perform additional post-build steps MUST observe the following order:
   binary region; nothing has been written past its OS-defined end yet, so
   the digest matches what the reader will recompute over
   ``[0, source_start)`` after the append.
-- **Append** ``<source><metadata><trailer>`` in a single write so a
+- **Append** ``<sources><metadata><trailer>`` in a single write so a
   partially written file fails the magic or hash check rather than
   appearing as a half-valid bundle.
 
@@ -282,10 +324,10 @@ Code Signing
 
 The bundle format itself does not require OS-level code signing.
 ``binary_sha256`` provides integrity against truncation, in-flight
-corruption, and naive tampering, and Airflow's threat model treats
-``executables_root`` as Deployment-Manager-controlled — *authenticity*
-(signed by a trusted identity) is a deployment-time concern rather than a
-bundle-format one.
+corruption, and naive tampering, and Airflow's threat model treats the Dag
+bundle holding the bundles as Deployment-Manager-controlled, so
+*authenticity* (signed by a trusted identity) is a deployment-time concern
+rather than a bundle-format one.
 
 **Compressors** such as UPX are NOT supported. They rewrite the file
 end-to-end, destroying both the trailer and the hash invariant.
@@ -298,22 +340,24 @@ yields a byte-identical bundle file (and therefore a stable
 Deployment Layout
 -----------------
 
-Bundle files are placed **as-is** in any of the directories configured as the
-``executables_root`` kwarg on the
+Bundle files are placed **as-is** in the Dag bundle named by the
+``task_handler_bundle_name`` kwarg on the
 :class:`~airflow.sdk.coordinators.executable.ExecutableCoordinator` entry
-under ``[sdk] coordinators``. The scanner walks each directory **recursively**
-and considers only regular files whose **executable bit is set** for the
-invoking user; files without the executable bit are skipped without reading
-their trailer. For each candidate it reads the last 64 bytes and treats files
+under ``[sdk] coordinators`` (or, when it is unset, in the task's own Dag
+bundle). The scanner walks the Dag bundle **recursively** and considers every
+regular file. For each candidate it reads the last 64 bytes and treats files
 whose magic matches ``"AFBNDL01"`` as bundles. Matched files are then
-SHA-256-verified per the reader algorithm; a mismatch demotes the file back
-to "ignored, with an error log." Files without the magic are silently
-ignored, so non-bundle files (READMEs, dotfiles) MAY share the directory
-without interfering with the scan.
+SHA-256-verified per the reader algorithm; a mismatch demotes the file back to
+"ignored, with an error log." Files without the magic are silently ignored, so
+non-bundle files (READMEs, dotfiles) MAY share the Dag bundle without
+interfering with the scan. A file that matches the selected bundle's
+``dag_id`` is marked executable before it is run, so an object-store Dag
+bundle (which has no concept of file permissions, and so cannot preserve the
+execute bit a build produced) works too.
 
 ::
 
-    /opt/airflow/executable-bundles/
+    /opt/airflow/go-task-handlers/
     ├── example
     ├── team-a/
     │   └── pipeline

{apache_airflow_task_sdk-1.3.2rc1 → apache_airflow_task_sdk-1.4.0b2}/docs/index.rst

@@ -86,6 +86,7 @@ Why use ``airflow.sdk``?
 - :class:`airflow.sdk.BaseOperator`
 - :class:`airflow.sdk.BaseOperatorLink`
 - :class:`airflow.sdk.BaseSensorOperator`
+- :class:`airflow.sdk.ChainRetryPolicy`
 - :class:`airflow.sdk.Connection`
 - :class:`airflow.sdk.Context`
 - :class:`airflow.sdk.DAG`
@@ -99,6 +100,7 @@ Why use ``airflow.sdk``?
 - :class:`airflow.sdk.RetryPolicy`
 - :class:`airflow.sdk.RetryRule`
 - :class:`airflow.sdk.TaskGroup`
+- :class:`airflow.sdk.LoopDecision`
 - :class:`airflow.sdk.TaskInstanceState`
 - :class:`airflow.sdk.DagRunState`
 - :class:`airflow.sdk.WeightRule`
@@ -178,4 +180,6 @@ For the full public API reference, see the :doc:`api` page.
   resumable-job-mixin
   api
   concepts
+  lang-sdk
   executable-bundle-spec
+  ts-bundle-spec