Fail constraints generation when a released provider is downgraded#69870
Open
potiuk wants to merge 2 commits into
Open
Fail constraints generation when a released provider is downgraded#69870potiuk wants to merge 2 commits into
potiuk wants to merge 2 commits into
Conversation
Released provider versions only ever move forward on PyPI, so a lower provider version in freshly generated PyPI constraints than in the already-published constraints is never intentional. It means the highest resolution dragged an old provider back in because a broken dependency version constrained it. Left unnoticed, such a downgrade would be committed to the constraints branch and shipped to users. The regular `constraints` generation now compares each released provider against the latest published constraints and stops with an error when any would be downgraded, so the problem surfaces in CI instead of being published. When it happens on the canary/push builds it also posts an alert to the CI Slack channel, since there is no PR author watching those runs, so maintainers learn about it immediately.
potiuk
requested review from
amoghrajesh,
ashb,
bugraoz93,
gopidesupavan,
jason810496 and
jscheffl
as code owners
boring-cyborg
Bot
added
area:dev-tools
backport-to-v3-3-test
1 task
The script read the gitignored, generated generated/provider_dependencies.json at import time. That file is not generated in the "Scripts tests" CI job, so importing the module (which the new tests do at collection) failed with FileNotFoundError and broke test collection. Only get_all_active_provider_distributions needs the data, so load it there instead of at module import, keeping the module importable without the generated artifact.
eladkal
approved these changes
Jul 14, 2026
eladkal
left a comment
eladkal
left a comment
Contributor
There was a problem hiding this comment.
This is great!
I do still think we need a validation step in the RM guide. I mean, RM can easily not see the open slack note and proceed with cutting release rather than check for resolution. cc @vatsrahul1001 WDYT?
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
2 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.
Regular
constraints(PyPI-providers) generation now fails, instead of silently publishing, when a releasedapache-airflow-providers-*package would be downgraded below the version already in the published constraints. Released providers only ever move forward on PyPI, so a downgrade means highest-resolution dragged an old provider back in because a broken dependency constrained it — the exact failure mode behind the recent databricks-sql-connector / thrift issue.The check compares each released provider against the latest published constraints and exits non-zero on any downgrade, so it surfaces in CI. On canary/push builds (where there is no PR author watching) it also posts an alert to the
#internal-airflow-ci-cdSlack channel via the existingslackapi/slack-github-action, so maintainers are notified immediately. The in-container step only writes the Slack payload; the workflow layer holds the token and sends it (skipped on fork PRs where no secret is available).Was generative AI tooling used to co-author this PR?
Generated-by: Claude Code (Opus 4.8) following the guidelines