Skip to content

Fix MongoToS3Operator aggregate-pipeline detection before rendering - #70330

Merged
shahar1 merged 1 commit into
apache:mainfrom
MannXo:fix/mongo-to-s3-template-field-init
Jul 24, 2026
Merged

Fix MongoToS3Operator aggregate-pipeline detection before rendering#70330
shahar1 merged 1 commit into
apache:mainfrom
MannXo:fix/mongo-to-s3-template-field-init

Conversation

@MannXo

@MannXo MannXo commented Jul 23, 2026

Copy link
Copy Markdown
Contributor

Compute the aggregate-vs-find decision in execute() from the rendered mongo_query, instead of caching self.is_pipeline = isinstance(self.mongo_query, list) in __init__.

mongo_query is a template field, so it is rendered after the constructor runs. Deriving is_pipeline in __init__ inspects the un-rendered Jinja expression, so a mongo_query that resolves to a list only after templating would be misclassified and sent through find() instead of aggregate(). Deciding in execute() uses the rendered value.

Part of the template-field constructor burn-down; removes the MongoToS3Operator entry from scripts/ci/prek/validate_operators_init_exemptions.txt in the same PR, as the hook requires.

related: #70296


Was generative AI tooling used to co-author this PR?
  • Yes — Claude Code (Opus 4.8)

Generated-by: Claude Code (Opus 4.8) following the guidelines

mongo_query is a template field, rendered after __init__ runs. Caching
is_pipeline = isinstance(self.mongo_query, list) in the constructor inspects
the un-rendered value, so a query that resolves to a list only after
templating would be sent through find() instead of aggregate(). Decide the
aggregate-vs-find path in execute() from the rendered value instead.
@shahar1
shahar1 merged commit c42540f into apache:main Jul 24, 2026
83 checks passed
@github-actions

Copy link
Copy Markdown
Contributor

Backport failed to create: v3-3-test. View the failure log Run details

Note: As of Merging PRs targeted for Airflow 3.X
the committer who merges the PR is responsible for backporting the PRs that are bug fixes (generally speaking) to the maintenance branches.

In matter of doubt please ask in #release-management Slack channel.

Status Branch Result
v3-3-test Commit Link

You can attempt to backport this manually by running:

cherry_picker c42540f v3-3-test

This should apply the commit to the v3-3-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

If you don't have cherry-picker installed, see the installation guide.

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

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants