Skip to content

Check Campaign Manager delete report arguments after rendering - #70530

Open
mitre88 wants to merge 1 commit into
apache:mainfrom
mitre88:fix-campaign-manager-delete-report
Open

Check Campaign Manager delete report arguments after rendering#70530
mitre88 wants to merge 1 commit into
apache:mainfrom
mitre88:fix-campaign-manager-delete-report

Conversation

@mitre88

@mitre88 mitre88 commented Jul 27, 2026

Copy link
Copy Markdown
Contributor

Part of the template-field validation burn-down tracked in #70296.

GoogleCampaignManagerDeleteReportOperator lists both report_name and report_id in template_fields but validates them with truthiness checks in __init__. A Jinja expression is always truthy, so templated values were never actually validated — a pair of expressions rendering to empty strings sailed through and execute silently did nothing. The checks now run at the start of execute() against the rendered values.

Since these are truthiness checks on rendered values (empty string counts as not provided), not pure is None provision checks, they are genuine under the relaxed definition proposed in #70505.

While touching them, the two raise AirflowException usages are narrowed to ValueError per the ongoing exception clean-up; the known_airflow_exceptions.txt entry for this file drops from 2 to 0.

Added a parametrized test that constructs the operator with a templated report_name and validates both failure modes at execute time — it fails against the previous implementation. The class is removed from the exemption list and both prek checks pass locally.

Note: a coordination note for this class was posted on #70296 on Jul 24, but no PR has appeared since; following the "better PR wins" convention rather than letting the entry stall.


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

Generated-by: Claude Code (Fable 5) following the guidelines

Both report_name and report_id are template fields, but the operator
verified them with truthiness checks in __init__, so a Jinja expression
always counted as provided and rendered values were never re-checked.
The checks now run at execute time on the rendered values, and the two
AirflowException usages are narrowed to ValueError per the ongoing
exception clean-up. Part of the burn-down tracked in apache#70296.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:dev-tools area:providers backport-to-v3-3-test Backport to v3-3-test provider:google Google (including GCP) related issues

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant