Conversation
vincbeck
requested review from
bbovenzi,
bugraoz93,
choo121600,
dheerajturaga,
ephraimbuddy,
guan404ming,
henry3260,
jason810496,
pierrejeambrun,
potiuk,
rawwar,
ryanahamilton,
shubhamraj-git and
vatsrahul1001
as code owners
September 17, 2026 20:21
boring-cyborg
Bot
added
area:API
vincbeck
force-pushed
the
vincbeck/jobs-team-column
branch
from
September 18, 2026 13:52
5f877f8 to
f7eb321
Compare
o-nikolas
reviewed
Sep 21, 2026
1 task
vincbeck
added a commit
to aws-mwaa/upstream-to-airflow
that referenced
this pull request
Sep 22, 2026
A Job's team scope was a single nullable column, which cannot describe a Dag processor that parses bundles belonging to more than one team. Scoping such a processor to no team at all loses the information that its work is relevant to each of those teams, so team coverage in the health endpoint and the team column in the UI cannot be derived from it. Raised in review of apache#73295.
| if not bundle_names: | ||
| return None | ||
|
|
||
| team_names = DagBundleModel.get_team_names(bundle_names) |
Contributor
There was a problem hiding this comment.
Maybe we should use _get_configured_bundle_team_names() from dag_processing/bundles/manager.py here instead, so the team comes from config instead of the DB? My agent told me:
At this point
sync_bundles()hasn't run yet (it happens insideDagFileProcessorManager.run(), afterrun_jobhas already committed the job row), so on a fresh deployment, or after a bundle moves to another team in config, the job would keep a missing or stale team until restart.airflow_health.pyalready resolves teams that way. It would also make a bareairflow dag-processorreturn the same team as--bundle-name a bwhen every configured bundle belongs to one team.
| bundle it parses belongs to the same team. A processor parsing all bundles, bundles of | ||
| several teams, or a team-less bundle alongside a team's own is not team-scoped. | ||
| """ | ||
| if not bundle_names: |
Contributor
There was a problem hiding this comment.
Should this also return None when [core] multi_team is off, like DagFileProcessorManager._get_team_names does?
| teams: Annotated[ | ||
| FilterParam[list[str]], | ||
| Depends( | ||
| filter_param_factory(Job.team_name, list[str], FilterOptionEnum.IN, "teams", default_factory=list) |
Contributor
There was a problem hiding this comment.
As far as I can tell, with the IN filter, there's no way to select jobs that have no team. Do you think that would be a problem?
Contributor
Author
There was a problem hiding this comment.
I would say let's leave it as is and if users need it, that's easy to implement
vincbeck
added a commit
to aws-mwaa/upstream-to-airflow
that referenced
this pull request
Sep 23, 2026
A Job's team scope was a single nullable column, which cannot describe a Dag processor that parses bundles belonging to more than one team. Scoping such a processor to no team at all loses the information that its work is relevant to each of those teams, so team coverage in the health endpoint and the team column in the UI cannot be derived from it. Raised in review of apache#73295.
vincbeck
added a commit
to aws-mwaa/upstream-to-airflow
that referenced
this pull request
Sep 24, 2026
A Job's team scope was a single nullable column, which cannot describe a Dag processor that parses bundles belonging to more than one team. Scoping such a processor to no team at all loses the information that its work is relevant to each of those teams, so team coverage in the health endpoint and the team column in the UI cannot be derived from it. Raised in review of apache#73295.
When multi-team mode is enabled, operators triaging scheduler, triggerer and Dag processor jobs need to see which team's workloads each job belongs to, and to scope the list to a single team when investigating that team's resource usage. The column and the filter render only when the `multi_team` configuration is enabled, so single-team deployments are unaffected.
vincbeck
force-pushed
the
vincbeck/jobs-team-column
branch
from
September 24, 2026 18:30
f7eb321 to
11aba40
Compare
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When multi-team mode is enabled, operators triaging scheduler, triggerer and Dag processor jobs need to see which team's workloads each job belongs to, and to scope the list to a single team when investigating that team's resource usage.
The column and the filter render only when the
multi_teamconfiguration is enabled, so single-team deployments are unaffected.Screenshot
Was generative AI tooling used to co-author this PR?
{pr_number}.significant.rst, in airflow-core/newsfragments. You can add this file in a follow-up commit after the PR is created so you know the PR number.