Tegh25 commented on code in PR #70416:
URL: https://github.com/apache/airflow/pull/70416#discussion_r3751943028
##########
airflow-core/src/airflow/jobs/job.py:
##########
@@ -101,6 +101,10 @@ class Job(Base, LoggingMixin):
executor_class: Mapped[str | None] = mapped_column(String(500))
hostname: Mapped[str | None] = mapped_column(String(500))
unixname: Mapped[str | None] = mapped_column(String(1000))
+ team_name: Mapped[str | None] = mapped_column(
+ String(50), ForeignKey("team.name", ondelete="SET NULL"), nullable=True
+ )
+ bundle_names: Mapped[list[str] | None] = mapped_column(ExtendedJSON,
nullable=True)
Review Comment:
`bundle_names` is the Dag-processor counterpart to `team_name` on
triggerers. Both are scope metadata on the job row so health / job APIs can
show what subset of work a given instance owns, not only that “some” instance
is alive.
A Dag processor is not limited to a single bundle. `airflow dag-processor
--bundle-name` is appendable, and
`DagFileProcessorManager.bundle_names_to_parse` is a `list[str] | None`. So the
column is a list to match that existing CLI/manager contract, e.g. one
processor for bundle-a + bundle-b, or several processors each with their own
subset in multi-team setups.
There are some test cases that also indicate that Dag processors can have
multiple bundles: [test_manager.py, lines
2783-2799](https://github.com/apache/airflow/blob/main/airflow-core/tests/unit/dag_processing/test_manager.py/#L2783-L2799)
Happy to rename/clarify in docs if “list” doesn't feel intuitive. the shape
follows the existing `--bundle-name` / `bundle_names_to_parse` behavior rather
than introducing a new one-bundle-per-processor constraint.
--
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]
