dkranchii commented on code in PR #68403:
URL: https://github.com/apache/airflow/pull/68403#discussion_r3507319822
##########
task-sdk/src/airflow/sdk/types.py:
##########
@@ -124,6 +124,7 @@ class DagRunProtocol(Protocol):
consumed_asset_events: list[AssetEventDagRunReference]
partition_key: str | None
note: str | None
+ team_name: str | None
Review Comment:
@ashb You're right that team_name is semantically a property of the Dag
(resolved through its bundle), not of the run - every DagRun of the same Dag
has the same team_name, and there's no team_name column on the DagRun ORM
either.
Where it does already live is the server-side Execution API DagRun payload -
it was added there (see AddTeamNameField in
execution_api/versions/v2026_06_16.py) so it can be delivered as part of
TIRunContext at task start, saving the worker an extra get_dag() round trip.
This PR is just keeping DagRunProtocol in sync with that server schema so SDK
consumers reading dag_run.team_name don't hit a type-checker failure.
I've pushed a comment on the field that spells this out - the
denormalization is a deliberate choice at the server-schema layer, not
something we're claiming is the "true" home of the field. If you'd rather see
this promoted to DagResponse (and thus DagResult on the SDK side) with
team_name removed from DagRun, happy to open a follow-up that does that
server-side refactor - but I think it's worth keeping the SDK protocol in sync
with the server as long as the server exposes it here.
--
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]
