Skip to content

[v3-3-test] Don't deactivate DAG bundles owned by other dag-processors (#69964)#70017

Merged
potiuk merged 1 commit into
v3-3-testfrom
backport-038ece6-v3-3-test
Jul 19, 2026
Merged

[v3-3-test] Don't deactivate DAG bundles owned by other dag-processors (#69964)#70017
potiuk merged 1 commit into
v3-3-testfrom
backport-038ece6-v3-3-test

Conversation

@github-actions

Copy link
Copy Markdown
Contributor

DagBundlesManager.sync_bundles_to_db() marks every stored bundle that is
not in the calling process's config as inactive. This assumes the caller
sees the complete bundle configuration.

When multiple dag-processors are each configured with a partial config (one
bundle per processor, a natural way to shard parsing), each processor treats
the other processors' bundles as "no longer found in config" and disables
them. Processor A disables B's bundle, B disables A's, and they flip
dag_bundle.active on every parse cycle -- the deployment never converges
and continuously logs "DAG bundle ... is no longer found in config and has
been disabled" for bundles that are actively configured elsewhere.

Add a deactivate_missing flag (default True, preserving existing
single-processor behavior) and have DagFileProcessorManager.sync_bundles()
pass deactivate_missing=False when the processor was started with a bundle
filter (--bundle-name / bundle_names_to_parse), i.e. when it only owns a
subset of the bundles.

closes: #69963
related: #69698
(cherry picked from commit 038ece6)

Co-authored-by: Sebastián Ortega sebastian.ortegatorres@datadoghq.com
Generated-by: Claude Code following the guidelines

#69964)

`DagBundlesManager.sync_bundles_to_db()` marks every stored bundle that is
not in the calling process's config as inactive. This assumes the caller
sees the complete bundle configuration.

When multiple dag-processors are each configured with a partial config (one
bundle per processor, a natural way to shard parsing), each processor treats
the other processors' bundles as "no longer found in config" and disables
them. Processor A disables B's bundle, B disables A's, and they flip
`dag_bundle.active` on every parse cycle -- the deployment never converges
and continuously logs "DAG bundle ... is no longer found in config and has
been disabled" for bundles that are actively configured elsewhere.

Add a `deactivate_missing` flag (default `True`, preserving existing
single-processor behavior) and have `DagFileProcessorManager.sync_bundles()`
pass `deactivate_missing=False` when the processor was started with a bundle
filter (`--bundle-name` / `bundle_names_to_parse`), i.e. when it only owns a
subset of the bundles.

closes: #69963
related: #69698
(cherry picked from commit 038ece6)

Co-authored-by: Sebastián Ortega <sebastian.ortegatorres@datadoghq.com>
Generated-by: Claude Code following the guidelines
@potiuk
potiuk marked this pull request as ready for review July 19, 2026 20:31
@potiuk
potiuk merged commit 7c77f8b into v3-3-test Jul 19, 2026
147 checks passed
@potiuk
potiuk deleted the backport-038ece6-v3-3-test branch July 19, 2026 21:51
@github-actions github-actions Bot added this to the Airflow 3.3.1 milestone Jul 19, 2026
@github-actions

Copy link
Copy Markdown
Contributor Author

Hi maintainer, this PR was merged without a milestone set.
We've automatically set the milestone to Airflow 3.3.1 based on: merged to version branch
If this milestone is not correct, please update it to the appropriate milestone.

This comment was generated by Milestone Tag Assistant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants