dkranchii commented on PR #68403: URL: https://github.com/apache/airflow/pull/68403#issuecomment-5185076563
@ashb Fair question - the intuition breaks down in three places, so it took me a bit to unpack too. **1. `team_name` is a property of the Dag Bundle, not the worker.** The design that landed for multi-team makes the relationship `Task → Dag → Dag Bundle → Team` (see [`airflow-core/docs/core-concepts/multi-team.rst`](https://github.com/apache/airflow/blob/main/airflow-core/docs/core-concepts/multi-team.rst)). Team lives on the bundle association only; DAG, DagRun, TaskInstance, worker, etc. all *infer* it from the bundle. That was a deliberate community decision when the feature was designed - `team_name` is not a first-class attribute of any of the runtime entities. **2. Not every worker/executor is per-team, and even where it is, the task subprocess doesn't inherit that arg.** - `airflow tasks run` (the process that actually executes user code) has no `--team-name` argument - task subprocesses don't get one, regardless of executor. - `KubernetesExecutor` launches a pod per task via `airflow tasks run`; the pod has no team CLI flag. - `LocalExecutor` runs in the scheduler process; the scheduler is process-wide, not team-scoped. Team-scoped `LocalExecutor`s are just another *instance* inside the same scheduler. - `CeleryExecutor` does have `airflow celery worker --team` on the *worker parent*, but the task subprocess it spawns still doesn't see it. - `EdgeWorker` has `--team-name`, but the docstring on that arg spells it out - "This is a UI/REST API-level hint; the Execution API does not currently enforce team-based access boundaries… If omitted, the worker operates as a default-team worker." ([`providers/edge3/src/airflow/providers/edge3/cli/definition.py`](https://github.com/apache/airflow/blob/main/providers/edge3/src/airflow/providers/edge3/cli/definition.py#L38-L50)) So "the worker process/config knows its team" is only true for Celery+Edge worker *parents*, and even there the value doesn't reach the task subprocess through any existing mechanism. **3. The server is the authoritative source, and it already ships this.** `get_team_name_for_ti` in [`airflow-core/src/airflow/api_fastapi/execution_api/security.py`](https://github.com/apache/airflow/blob/main/airflow-core/src/airflow/api_fastapi/execution_api/security.py) resolves the task's team from `TaskInstance → DagModel → DagBundleModel → Team` and the `ti_run` route stamps it onto `DagRun.team_name` in `TIRunContext`. That happened in [#65617 (Add team name to task CTX)](https://github.com/apache/airflow/pull/65617) with a versioned schema change (`AddTeamNameField` in `execution_api/versions/v2026_04_17.py`), and the SDK's generated `_generated.py` `DagRun` model already carries the field. It's what populates `AIRFLOW_CTX_TEAM_NAME` for user code today. Even if we later added a worker-side arg, we'd still want the server value to be authoritative - the DB-resolved bundle mapping is the single source of truth and can't drift or be spoofed by a mis-passed CLI flag. **Scope of this PR.** Given all of the above, this PR is *only* a typing sync: the field is already in `TIRunContext.dag_run` and already surfaces in user context, but `DagRunProtocol` (the `Protocol` used to type `context["dag_run"]`) was last synced before #65617 and lags. Type checkers therefore flag `context["dag_run"].team_name` as `[attr-defined]` today. This 8-line change closes that gap; no runtime behaviour changes. If you'd rather see `team_name` moved off `DagRun` server-side (e.g. promoted to `DagResponse` / `DagResult`), I'm happy to open a follow-up for that architectural discussion - but it's a separate conversation from keeping the SDK protocol aligned with what the server already ships. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
