Explain dag_bundle_name by the coordinator that parses a Dag file

dag_bundle_name lets Dag processing pick which of several coordinators
of one class starts the runtime that parses an artifact. With a single
coordinator it can be omitted. Reword the Java, TypeScript and Go docs
and READMEs to say so, without tying it to the Python stub Dag.

Co-Authored-By: Claude <noreply@anthropic.com>

Author: jason810496

airflow-core/docs/authoring-and-scheduling/language-sdks/go.rst

@@ -207,12 +207,11 @@ then register the coordinator and route the queue to it in ``airflow.cfg`` (or t
     }
     queue_to_coordinator = {"golang": "go"}
 
-``dag_bundle_name`` is optional. Omit it and the coordinator finds executable bundles in the task's own Dag
-bundle, the one that holds the Python stub Dag. Set it, as here, to keep them in a separate Dag bundle, for
-example when you configure more than one ``ExecutableCoordinator`` and each has its own bundles.
-``queue_to_coordinator``
-routes stub tasks with ``queue="golang"`` to this Go coordinator. See :ref:`go-sdk/coordinator-config` for
-the full list of accepted ``kwargs``.
+``dag_bundle_name`` is only needed when you configure more than one ``ExecutableCoordinator``. Each one must
+then name its own Dag bundle, so Dag processing knows which one runs an executable bundle to parse it. With a
+single ``ExecutableCoordinator``, as here, it is optional: omit it and the coordinator finds executable bundles
+in the task's own Dag bundle. ``queue_to_coordinator`` routes stub tasks with ``queue="golang"`` to this Go
+coordinator. See :ref:`go-sdk/coordinator-config` for the full list of accepted ``kwargs``.
 
 There is no separate Go worker to run: the Airflow worker forks the bundle binary once per task instance.
 
@@ -502,7 +501,7 @@ Deploying
 ~~~~~~~~~
 
 Copy or mount the packed bundle into the Dag bundle the coordinator scans: the one named by
-``dag_bundle_name``, or the stub Dag's own bundle. The
+``dag_bundle_name``, or the task's own Dag bundle. The
 :class:`~airflow.sdk.coordinators.executable.ExecutableCoordinator` scans that Dag bundle recursively,
 matches the incoming ``dag_id`` against each bundle's manifest, verifies the bundle's integrity hash, and
 launches the matching bundle. Bundles are identified by the trailer magic, not by filename (no extension on
@@ -526,7 +525,8 @@ All ``kwargs`` in the ``coordinators`` config entry are passed to the
    * - ``dag_bundle_name``
      - *(auto: task's own bundle)*
      - Name of a configured Dag bundle to load executable bundles from. It must name a bundle in
-       ``[dag_processor] dag_bundle_config_list``.
+       ``[dag_processor] dag_bundle_config_list``. Only needed when more than one
+       ``ExecutableCoordinator`` is configured.
    * - ``task_startup_timeout``
      - ``10.0``
      - Seconds to wait for the bundle subprocess to connect after launch. Increase this if your
@@ -537,10 +537,11 @@ All ``kwargs`` in the ``coordinators`` config entry are passed to the
   **Locating bundles.** Executable bundles always live in a Dag bundle:
 
   * Leave ``dag_bundle_name`` unset (the default) to load bundles from the **task's own** Dag bundle,
-    pinned to the version the run was created with.
-  * Set ``dag_bundle_name`` to keep bundles in a separate Dag bundle, for example one per
-    ``ExecutableCoordinator`` when you configure more than one. The task uses the version that Dag
-    bundle is on when it starts, pinned for the whole task.
+    pinned to the version the run was created with. This is all you need with a single
+    ``ExecutableCoordinator``.
+  * With more than one ``ExecutableCoordinator``, set ``dag_bundle_name`` on each to a different Dag
+    bundle, so Dag processing knows which one runs an executable bundle to parse it. The task uses the
+    version that Dag bundle is on when it starts, pinned for the whole task.
 
 .. _go-sdk/limitations:
 

airflow-core/docs/authoring-and-scheduling/language-sdks/java.rst

@@ -274,10 +274,10 @@ Configure Airflow so the parent JAR directory is a Dag bundle, the coordinator s
     }
     queue_to_coordinator = {"java": "java"}
 
-``dag_bundle_name`` is only needed when you configure more than one ``JavaCoordinator``. Each one must then
-name its own Dag bundle, otherwise the Dag importer cannot tell which coordinator should parse a JAR. With a
-single ``JavaCoordinator``, as here, it is optional: omit it and the coordinator finds the JARs in the task's
-own Dag bundle, the one that holds ``sales_pipeline.py``.
+``dag_bundle_name`` is only needed when you configure more than one ``JavaCoordinator``, for example ``jdk-11``
+and ``jdk-17``. Each one must then name its own Dag bundle, so Dag processing knows which one starts the JVM
+that parses a JAR. With a single ``JavaCoordinator``, as here, it is optional: omit it and the coordinator finds
+the JARs in the task's own Dag bundle.
 
 ``java`` is a user-chosen coordinator name, not a reserved value. The value assigned to the queue in
 ``queue_to_coordinator`` must match a key in ``coordinators``.
@@ -1090,7 +1090,7 @@ All ``kwargs`` in the ``coordinators`` config entry are passed to the
   * Leave ``dag_bundle_name`` unset (the default) to load JARs from the **task's own** Dag bundle, pinned
     to the version the run was created with. This is all you need with a single ``JavaCoordinator``.
   * With more than one ``JavaCoordinator``, set ``dag_bundle_name`` on each to a different Dag bundle, so
-    the Dag importer can tell which coordinator parses which JAR. The task uses the version that bundle is
+    Dag processing knows which one starts the JVM that parses a JAR. The task uses the version that bundle is
     on when it starts, pinned for the whole task.
 
 .. note::

airflow-core/docs/authoring-and-scheduling/language-sdks/typescript.rst

@@ -238,10 +238,10 @@ variables):
     }
     queue_to_coordinator = {"typescript": "ts"}
 
-``dag_bundle_name`` is only needed when you configure more than one ``NodeCoordinator``. Each one must then
-name its own Dag bundle, otherwise the Dag importer cannot tell which coordinator should parse a ``*.min.mjs``
-bundle. With a single ``NodeCoordinator``, as here, it is optional: omit it and the coordinator finds the
-bundles in the task's own Dag bundle, the one that holds the Python stub Dag. ``queue_to_coordinator`` routes stub tasks with
+``dag_bundle_name`` is only needed when you configure more than one ``NodeCoordinator``, for example one per
+Node.js version. Each one must then name its own Dag bundle, so Dag processing knows which one starts Node.js
+to parse a ``*.min.mjs`` bundle. With a single ``NodeCoordinator``, as here, it is optional: omit it and the
+coordinator finds the bundles in the task's own Dag bundle. ``queue_to_coordinator`` routes stub tasks with
 ``queue="typescript"`` to this coordinator. See :ref:`typescript-sdk/coordinator-config` for the full list
 of accepted ``kwargs``.
 
@@ -526,7 +526,7 @@ Deploying
 ~~~~~~~~~
 
 Copy or mount the bundle into the Dag bundle the coordinator scans: the one named by ``dag_bundle_name``,
-or the stub Dag's own bundle. :class:`~airflow.sdk.coordinators.node.NodeCoordinator` searches that Dag
+or the task's own Dag bundle. :class:`~airflow.sdk.coordinators.node.NodeCoordinator` searches that Dag
 bundle recursively and launches the first integrity-verified ``*.min.mjs`` bundle whose metadata declares the
 task instance's Dag. The artifact's name does not matter beyond that suffix, so one Dag bundle can hold several
 bundles and a Dag is routed to whichever declares it. If multiple bundles declare the same Dag, the first in
@@ -567,7 +567,7 @@ All ``kwargs`` in the ``coordinators`` config entry are passed to the
   * Leave ``dag_bundle_name`` unset (the default) to load the bundle from the **task's own** Dag bundle,
     pinned to the version the run was created with. This is all you need with a single ``NodeCoordinator``.
   * With more than one ``NodeCoordinator``, set ``dag_bundle_name`` on each to a different Dag bundle, so
-    the Dag importer can tell which coordinator parses which bundle. The task uses the version that Dag
+    Dag processing knows which one starts Node.js to parse a bundle. The task uses the version that Dag
     bundle is on when it starts, pinned for the whole task.
 
 Limitations

go-sdk/README.md

@@ -292,9 +292,10 @@ the full range of task states, and alternate XCom backends without implementing
   queue_to_coordinator = {"golang": "go"}
   ```
 
-  `dag_bundle_name` is optional. Omit it and the coordinator finds executable bundles in the task's own
-  Dag bundle, the one that holds the Python stub Dag. Set it, as here, to keep them in a separate Dag bundle. `queue_to_coordinator` routes stub tasks with
-  `queue="golang"` to this Go coordinator.
+  `dag_bundle_name` is only needed when more than one `ExecutableCoordinator` is configured. Each one must
+  then name its own Dag bundle, so Dag processing knows which one runs an executable bundle to parse it. With
+  a single `ExecutableCoordinator` it is optional: omit it and the coordinator finds executable bundles in the
+  task's own Dag bundle. `queue_to_coordinator` routes stub tasks with `queue="golang"` to this Go coordinator.
 
   > [!IMPORTANT]
   > The coordinator is part of the Airflow worker, so the `[sdk]` config (and the executable bundle

java-sdk/README.md

@@ -120,8 +120,10 @@ Now `cd example` into the example project, and
   export AIRFLOW__SDK__QUEUE_TO_COORDINATOR='{"java": "java"}'
   ```
 
-  With a single `JavaCoordinator`, `dag_bundle_name` is optional. It is set here because the JARs live in
-  `build/bundle`, outside the Dags folder; omit it if you ship the JARs in the same Dag bundle as the stub Dag.
+  `dag_bundle_name` is only needed when more than one `JavaCoordinator` is configured, for example `jdk-11` and
+  `jdk-17`. Each one must then name its own Dag bundle, so Dag processing knows which one starts the JVM that
+  parses a JAR. With a single `JavaCoordinator` it is optional: omit it and the coordinator finds the JARs in the
+  task's own Dag bundle.
 
 * Ensure the Connection and Variable needed by the example DAG are available:
 

ts-sdk/README.md

@@ -98,11 +98,11 @@ coordinators = {
 queue_to_coordinator = {"typescript": "ts"}
 ```
 
-The stub Dag's own Dag bundle is searched recursively for `*.min.mjs` bundles built with `airflow-ts-pack`
+The task's own Dag bundle is searched recursively for `*.min.mjs` bundles built with `airflow-ts-pack`
 (see [Packing bundles](#packing-bundles)), which embeds the Airflow metadata in the bundle itself. Set
-`dag_bundle_name` only when you configure more than one `NodeCoordinator`: each must then name its own Dag
-bundle from `[dag_processor] dag_bundle_config_list`, otherwise the Dag importer cannot tell which coordinator
-should parse a bundle.
+`dag_bundle_name` only when you configure more than one `NodeCoordinator`, for example one per Node.js version.
+Each one must then name its own Dag bundle from `[dag_processor] dag_bundle_config_list`, so Dag processing
+knows which one starts Node.js to parse a bundle.
 
 TypeScript entrypoint:
 

ts-sdk/example/README.md

@@ -83,8 +83,10 @@ export AIRFLOW__SDK__COORDINATORS='{
 export AIRFLOW__SDK__QUEUE_TO_COORDINATOR='{"typescript": "ts"}'
 ```
 
-With a single `NodeCoordinator`, `dag_bundle_name` is optional. It is set here because the bundle lives in
-`dist/`, outside the Dags folder; omit it if you copy the bundle into the same Dag bundle as the stub Dags.
+`dag_bundle_name` is only needed when more than one `NodeCoordinator` is configured, for example one per
+Node.js version. Each one must then name its own Dag bundle, so Dag processing knows which one starts Node.js
+to parse a bundle. With a single `NodeCoordinator` it is optional: omit it and the coordinator finds the bundle
+in the task's own Dag bundle.
 
 Copy both files in `dags/` into your Airflow Dags folder.