Repository navigation
[v3-4-test] Keep release-candidate provider pins until each is released or yanked (#75919) - #75924
Merged
Merged
Conversation
…ed or yanked (#75919) Constraints for an Airflow release candidate pin the provider wave being voted on at its rc versions, and commit them onto the shared constraints-X-Y branch. The next regular generation for the vX-Y-test branch resolves without pre-releases, so it saw the older finals as a provider downgrade and failed - the v3-4-test canary has been red since 3.4.0rc1 for exactly that reason, although nothing was yanked. The final release has the opposite gap: it ignored the candidates, so a provider rc that was neither released nor yanked was silently passed over and the released constraints never recorded that decision. It now has to be made, and the run says which providers it is still waiting on. The alert that should have reported the canary failure never reached Slack because the action was not told which API method to call, and the twice-daily CI notification announced "All passing" because it read a run that was still in progress, whose missing conclusion looked like no failures. (cherry picked from commit eeae004) Co-authored-by: Jarek Potiuk <jarek@potiuk.com> Generated-by: Claude Opus 5
1 task done
vatsrahul1001
marked this pull request as ready for review
October 29, 2026 05:14
vatsrahul1001
requested review from
amoghrajesh,
ashb,
bugraoz93,
choo121600,
ephraimbuddy,
gopidesupavan,
jason810496,
jedcunningham,
jscheffl,
potiuk,
shahar1,
vatsrahul1001 and
vincbeck
as code owners
October 29, 2026 05:14
Contributor
Author
|
RunsOn re-runs them automatically when the run finishes; no action is needed. |
shahar1
approved these changes
Oct 29, 2026
shahar1
enabled auto-merge (squash)
October 29, 2026 06:31
vatsrahul1001
pushed a commit
that referenced
this pull request
Oct 30, 2026
…ed or yanked (#75919) (#75924) Constraints for an Airflow release candidate pin the provider wave being voted on at its rc versions, and commit them onto the shared constraints-X-Y branch. The next regular generation for the vX-Y-test branch resolves without pre-releases, so it saw the older finals as a provider downgrade and failed - the v3-4-test canary has been red since 3.4.0rc1 for exactly that reason, although nothing was yanked. The final release has the opposite gap: it ignored the candidates, so a provider rc that was neither released nor yanked was silently passed over and the released constraints never recorded that decision. It now has to be made, and the run says which providers it is still waiting on. The alert that should have reported the canary failure never reached Slack because the action was not told which API method to call, and the twice-daily CI notification announced "All passing" because it read a run that was still in progress, whose missing conclusion looked like no failures. (cherry picked from commit eeae004) Generated-by: Claude Opus 5 Co-authored-by: Jarek Potiuk <jarek@potiuk.com>
shahar1
pushed a commit
that referenced
this pull request
Nov 6, 2026
…er.get_jwt_refresh_middleware()` (#75868) * [v3-4-test] Keep release-candidate provider pins until each is released or yanked (#75919) (#75924) Constraints for an Airflow release candidate pin the provider wave being voted on at its rc versions, and commit them onto the shared constraints-X-Y branch. The next regular generation for the vX-Y-test branch resolves without pre-releases, so it saw the older finals as a provider downgrade and failed - the v3-4-test canary has been red since 3.4.0rc1 for exactly that reason, although nothing was yanked. The final release has the opposite gap: it ignored the candidates, so a provider rc that was neither released nor yanked was silently passed over and the released constraints never recorded that decision. It now has to be made, and the run says which providers it is still waiting on. The alert that should have reported the canary failure never reached Slack because the action was not told which API method to call, and the twice-daily CI notification announced "All passing" because it read a run that was still in progress, whose missing conclusion looked like no failures. (cherry picked from commit eeae004) Generated-by: Claude Opus 5 Co-authored-by: Jarek Potiuk <jarek@potiuk.com> * Make JWTRefreshMiddleware extensible via BaseAuthManager.get_jwt_refresh_middleware() (#70783) Co-authored-by: Stephen Bracken <email-protected> (cherry picked from commit e5d8cbb) --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Jarek Potiuk <jarek@potiuk.com> Co-authored-by: stephen-bracken <18257727+stephen-bracken@users.noreply.github.com>
shahar1
added a commit
that referenced
this pull request
Nov 6, 2026
…#75869) * [v3-4-test] Keep release-candidate provider pins until each is released or yanked (#75919) (#75924) Constraints for an Airflow release candidate pin the provider wave being voted on at its rc versions, and commit them onto the shared constraints-X-Y branch. The next regular generation for the vX-Y-test branch resolves without pre-releases, so it saw the older finals as a provider downgrade and failed - the v3-4-test canary has been red since 3.4.0rc1 for exactly that reason, although nothing was yanked. The final release has the opposite gap: it ignored the candidates, so a provider rc that was neither released nor yanked was silently passed over and the released constraints never recorded that decision. It now has to be made, and the run says which providers it is still waiting on. The alert that should have reported the canary failure never reached Slack because the action was not told which API method to call, and the twice-daily CI notification announced "All passing" because it read a run that was still in progress, whose missing conclusion looked like no failures. (cherry picked from commit eeae004) Generated-by: Claude Opus 5 Co-authored-by: Jarek Potiuk <jarek@potiuk.com> * Make JWTRefreshMiddleware extensible via BaseAuthManager.get_jwt_refresh_middleware() (#70783) Co-authored-by: Stephen Bracken <email-protected> (cherry picked from commit e5d8cbb) * Keep extra cookies set by a route in JWTRefreshMiddleware (#75411) * Keep extra cookies set by a route in JWTRefreshMiddleware The route-wins rule only covered the token cookie, so a cookie returned by get_extra_cookies was still appended after the same cookie set by the route. When the session was invalidated, that cleared the cookie a login callback had just issued. The generate_new_user_token test passed one-element tuples to a single parametrized argument, so the case without a new user never ran. * Split token and cleanup cookie handling in JWTRefreshMiddleware * Let route cookies win by sending the middleware cookies first Browsers key cookies on name and path, so matching the route's cookies by name alone dropped our clear when the route set the same name on another path. Sending our headers before the route's lets the later Set-Cookie win for the same name and path, without parsing them. * Never send a refreshed token when the route sets its own Sending the refreshed token first and letting the route's logout cookie override it still put a freshly minted, unrevoked JWT on the wire, and clients such as Python's http.cookiejar keep it because they don't apply Set-Cookie headers in order. (cherry picked from commit ea2aae7) --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: Jarek Potiuk <jarek@potiuk.com> Co-authored-by: stephen-bracken <18257727+stephen-bracken@users.noreply.github.com> Co-authored-by: Shahar Epstein <60007259+shahar1@users.noreply.github.com>
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
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.
Constraints for an Airflow release candidate pin the provider wave being
voted on at its rc versions, and commit them onto the shared
constraints-X-Y branch. The next regular generation for the vX-Y-test
branch resolves without pre-releases, so it saw the older finals as a
provider downgrade and failed - the v3-4-test canary has been red since
3.4.0rc1 for exactly that reason, although nothing was yanked.
The final release has the opposite gap: it ignored the candidates, so a
provider rc that was neither released nor yanked was silently passed
over and the released constraints never recorded that decision. It now
has to be made, and the run says which providers it is still waiting on.
The alert that should have reported the canary failure never reached
Slack because the action was not told which API method to call, and the
twice-daily CI notification announced "All passing" because it read a
run that was still in progress, whose missing conclusion looked like no
failures.
(cherry picked from commit eeae004)
Co-authored-by: Jarek Potiuk jarek@potiuk.com
Generated-by: Claude Opus 5