Skip to content

Status of testing Providers that were prepared on September 09, 2026 #72902

Description

@vincbeck

I have a kind request for all the contributors to the latest provider distributions release.
Could you please help us to test the RC versions of the providers?

The guidelines on how to test providers can be found in

Verify providers by contributors

Let us know in the comments, whether the issue is addressed.

These are providers that require testing as there were some substantial changes introduced:

Provider akeyless: 0.3.1rc1

Provider amazon: 9.36.0rc1

Provider anthropic: 1.0.0rc1

Provider apache.beam: 6.2.4rc1

Provider apache.hive: 9.6.2rc1

Provider apache.iceberg: 2.1.1rc1

Provider apache.kafka: 2.0.0rc1

Provider celery: 3.24.0rc1

Provider cncf.kubernetes: 10.22.0rc1

Provider cohere: 1.7.0rc1

Provider common.ai: 0.9.0rc1

Provider common.compat: 1.19.0rc1

Provider common.io: 1.9.0rc1

Provider common.messaging: 2.1.0rc1

Provider databricks: 7.20.0rc1

Provider edge3: 4.3.2rc1

Provider exasol: 4.10.6rc1

Provider fab: 3.9.0rc1

Provider git: 0.5.0rc1

Provider google: 22.5.0rc1

Provider http: 6.1.0rc1

Provider influxdb: 2.11.1rc1

Provider informatica: 0.2.1rc1

Provider jdbc: 5.6.0rc1

Provider keycloak: 0.10.0rc1

Provider microsoft.azure: 15.1.0rc1

Provider odbc: 4.13.0rc1

Provider opensearch: 1.12.1rc1

Provider pagerduty: 5.2.7rc1

Provider redis: 4.6.0rc1

Provider snowflake: 6.17.0rc1

Provider standard: 1.19.0rc1

Provider teradata: 3.6.3rc1

Provider yandex: 4.5.2rc1

Provider ydb: 2.6.0rc1

All users involved in the PRs:
@nandeshkanagaraju @olegkachur-e @xBis7 @amoghrajesh @Sdnsoumy @RaphCodec @jayamanikharyono @dheerajturaga @w-shahid @kacpermuda @peloyeje @Crowiant @Lee-W @baha-bouali @MaksYermak @justinpakzad @23tae @rjgoyln @raphaelauv @MarthalaJagruthiReddy @mitre88 @ramitkataria @jeff3071 @Samin061 @dabla @zohaibfast99 @ahilashsasidharan @pankajastro @bingqin2 @ColtenOuO @Priyaj11 @vikramkoka @moomindani @kada2004 @weiyu1029 @stephen-bracken @guan404ming @yuseok89 @lubimow-xwf @joseph-bergin @edsu @molcay @LE0-Lin @KSchmidAmilar @AlejandroMorgante @henry3260 @o-nikolas @simar-rekhi @SameerMesiah97 @FrankYang0529 @Har1sh-k @SEPURI-SAI-KRISHNA @aaron-y-chen @Vamsi-klu @zach-overflow @keith991001 @jason810496 @steveahnahn @KidAmnesiac1 @vincbeck @potiuk

Activity

  1. added
    kind:metaHigh-level information important to the community
    on Sep 10, 2026
  2. changed the title [-]Status of testing Providers that were prepared on <MONTH DD, YYYY>[/-] [+]Status of testing Providers that were prepared on September 10, 2026[/+] on Sep 10, 2026
  3. changed the title [-]Status of testing Providers that were prepared on September 10, 2026[/-] [+]Status of testing Providers that were prepared on September 09, 2026[/+] on Sep 10, 2026
  4. 1fanwang commented on Sep 10, 2026

    @1fanwang
    Contributor

    Tested my changes working for on Python 3.12.14 and Airflow 3.3.1 on apache-airflow-providers-databricks==7.20.0rc1 : the behavior in #70831, related to #70340, is correct. A Dag that passes both  statement  and  statement_id  now fails during parsing with  ValueError: Provide exactly one of statement or statement_id. , including  statement_id=""  and a template that renders to  None . Both cases executed  SELECT 1  with 7.19.0. A statement-only control still ran successfully. A lone statement template that rendered to  None  failed after rendering with  ValueError: One of either statement or statement_id must be provided. 

  5. 1fanwang commented on Sep 10, 2026

    @1fanwang
    Contributor

    Tested my changes working for on Python 3.12.14 and Airflow 3.3.1 on apache-airflow-providers-apache-iceberg==2.1.1rc1 : #72312 correctly supersedes #72173. Using a real  AssetStateStoreAccessors  and a real local Iceberg catalog and table, a restarted watcher at the stored snapshot emitted nothing. After a new snapshot, it emitted once and persisted the new watermark. The Airflow 3.3.1 accessor has no  aget , and the RC did not call it.

  6. Priyaj11 commented on Sep 10, 2026

    @Priyaj11
    Contributor

    Tested amazon 9.36.0rc1 for #72500 (EmrContainerSensor reporting success or an unknown job state). Installed apache-airflow-providers-amazon==9.36.0rc1 into an Airflow 3.1.3
    virtualenv (Python 3.12) and exercised EmrContainerSensor.poke() against each state path with the hook mocked:
    COMPLETED -> True
    RUNNING -> False
    FAILED -> raises AirflowException
    SOME_FUTURE_STATE -> False
    None -> False
    The last two are the fix: an unrecognised state and a None response from the hook now keep the sensor poking instead of reporting success. The known states are unaffected.
    Works as expected from my side.

  7. zach-overflow commented on Sep 10, 2026

    @zach-overflow
    Contributor

    Looks good for my change (251cd91) from main (tested using a9f6c89). Tests for pagerduty, anthropic, and google all pass; The ast-grep hook I added also passes. That said, there were 6 openlineage dataproc-injection failures which are pre-existing and unrelated to the httpx2 switch, and they reproduce on main latest as well.

    I verified the RCs from PyPI in a clean 3.10 venv: google 22.5.0rc1, pagerduty 5.2.7rc1, anthropic 1.0.0rc1. Pins are right, and I exercised the real paths, not just imports — the cloud-sql proxy download via httpcore2 succeeded with truststore / TLS. send_event had a valid, successful httpx2.Response returning the dedup key. httpx is still in that venv but only transitively via google's other deps.

  8. justinpakzad commented on Sep 10, 2026

    @justinpakzad
    Contributor

    #72602, #70103, and #71659 are all working as expected. Tested the new changes against a live Snowflake instance with variety of success and failure paths.

  9. bingqin2 commented on Sep 11, 2026

    @bingqin2
    Contributor

    Tested #72824 on Python 3.12.13 with apache-airflow 3.3.1 and apache-airflow-providers-amazon==9.36.0rc1: EcsTaskFailToStart, EcsOperatorError and WaiterTerminalFailure all survive a pickle.dumps / pickle.loads round-trip with their message, failures and last_response intact. Works as expected, thanks.

  10. keith991001 commented on Sep 11, 2026

    @keith991001
    Contributor

    Hi, Tested my change working on Python 3.12.13 and Airflow 3.3.1 with apache-airflow-providers-common-compat==1.19.0rc1: #72509 behaves as expected. Using real attrs 26.1.0 entities in a clean environment, constructing two Table instances and appending a Tag to one no longer leaks into the other — tags, columns, owners, and extra are all per-instance now, and Column.tags is
    isolated the same way. Mutations also no longer bleed into the class defaults, so freshly constructed instances start empty as they should. +1 (non-binding)

  11. moomindani commented on Sep 11, 2026

    @moomindani
    Contributor

    Tested the databricks 7.20.0 candidate wheel from dist/dev/airflow/providers/2026-09-09/ (sha512 verified) in a clean venv, so the code under test came from the packaged artifact rather than a source checkout — airflow 3.3.1, provider resolved from site-packages.

    One job covers both of my items: 101 condition_task entries push the run's task list past the API's 100-per-page limit, and a trailing always-failing notebook task with max_retries: 1 produces two attempt entries for a single task_key. Run against a live workspace, terminal result_state FAILED as intended.

    #72304 — get_run() returned 103 entries where it previously stopped at 100, get_run_tasks() agreed exactly (103 = 103), and all 102 declared task_keys were present.

    #72313 — the API returned two attempts for the failing task (attempt_number 0 and 1, distinct run ids) and extract_failed_task_errors reported it once, carrying the last attempt's run id.

    Both good from me.


    Drafted-by: Claude Code (Opus 5); reviewed by @moomindani before posting

  12. nandeshkanagaraju commented on Sep 11, 2026

    @nandeshkanagaraju
    Contributor

    Tested amazon 9.36.0rc1 for Fix region_name being ignored by the Step Functions execution trigger (#72625) — works as expected ✅

    Installed the RC from PyPI into a clean venv (Python 3.12, apache-airflow==3.3.1, apache-airflow-task-sdk==1.3.1) and verified against the installed distribution (not a source checkout), with AWS_DEFAULT_REGION=us-east-1 so a regression would be visible:

    • StepFunctionsExecutionCompleteTrigger(execution_arn=..., region_name="eu-west-1") → trigger.region_name == "eu-west-1", and the hook the deferred waiter polls with builds a boto3 client in eu-west-1.
    • serialize() round-trip keeps region_name, and the rebuilt trigger still polls eu-west-1 (so the region survives a triggerer restart).
    • With no region_name passed, it still falls back to the connection/env default (us-east-1) — no regression for existing DAGs.
    • End-to-end via StepFunctionStartExecutionOperator(deferrable=True, region_name="eu-west-1"): the TaskDeferred trigger carries the region and polls eu-west-1.
    • The unit tests added in the PR (providers/amazon/tests/unit/amazon/aws/triggers/test_step_function.py) pass against the RC wheel: 3 passed.

    Negative control on the previous release 9.35.1 reproduces the original bug — trigger.region_name is None and the waiter client is created in us-east-1 despite region_name="eu-west-1" being passed.

    Thanks for preparing the release!

  13. KidAmnesiac1 commented on Sep 11, 2026

    @KidAmnesiac1
    Contributor

    #72197 looks good. 🫡

  14. xBis7 commented on Sep 11, 2026

    @xBis7
    Contributor

    Tested provider apache kafka 2.0.0rc1 manually and everything looks good!

    My changes are adding an allowlist for configured callbacks in a connection. I created a connection with an unknown callback and ran a dag. The task using the connection failed as expected with the correct error.

  15. 1 remaining item

  16. yuseok89 commented on Sep 11, 2026

    @yuseok89
    Contributor

    Tested apache-airflow-providers-amazon==9.36.0rc1 for #72497 against a real GCS bucket and a real S3 bucket. Works as expected.

  17. rjgoyln commented on Sep 11, 2026

    @rjgoyln
    Contributor

    Tested all four items from a clean Python 3.12 venv with apache-airflow==3.3.1 and the RC wheels installed from PyPI. Each scenario was run against both the RC and previous release as a control.

    All four work as expected from my side.

  18. Har1sh-k commented on Sep 11, 2026

    @Har1sh-k
    Contributor

    Tested apache.hive 9.6.2rc1 for #66751, installed from PyPI into a clean venv on Airflow 3.3.1 (with mysql 6.6.2 and presto 5.12.1). Works for me.

    What I exercised, driving HiveStatsCollectionOperator.execute with the metastore, Presto and MySQL hooks stubbed and capturing the SQL and parameters:

    • The Presto stats query renders the WHERE clause with the hook's own placeholder and passes the partition values through get_first(sql, parameters=...), so the values are no longer interpolated into the statement.
    • The hive_stats SELECT and the DELETE on the previous-run path both use %s with parameters=, binding table name, partition repr and dttm.
    • Identifier quoting behaves as intended: a hyphenated column and partition key come out as "weird-col" and "dt-col", db.odd-table becomes db."odd-table" with the catalog left plain, db."already.quoted" is passed through without being re-escaped, and plain word identifiers are still emitted unquoted. That is the case that used to produce an invalid statement.
  19. AlejandroMorgante commented on Sep 11, 2026

    @AlejandroMorgante
    Contributor

    Validated apache-airflow-providers-cncf-kubernetes==10.22.0rc1 — #71244: example_kubernetes_pod_exec.py passed against a temporary Kubernetes 1.31.5 k3d cluster (1 passed). Pod creation and readiness, command execution in the existing container, stdout returned through XCom, Pod deletion, and post-test cleanup were verified.

    Environment: Breeze, Airflow 3.1.3, Python 3.10

  20. Vamsi-klu commented on Sep 11, 2026

    @Vamsi-klu
  21. 23tae commented on Sep 12, 2026

    @23tae
    Contributor

    Tested apache-airflow-providers-cncf-kubernetes==10.22.0rc1 for #68890. (Environment: Breeze, Airflow 3.3.1, Python 3.12)

    Verified that KubernetesPodOperator._set_name:

    • Accepts valid pod names without errors.
    • Raises the expected validation exception (AirflowException on Airflow 3.3.1) when the name exceeds the limit, confirming backward compatibility.
  22. SameerMesiah97 commented on Sep 12, 2026

    @SameerMesiah97
    Contributor

    apache-airflow-providers-amazon==9.36.0rc1

    PR #72455: Changes are working as expected with no observed regresssions.

  23. steveahnahn commented on Sep 12, 2026

    @steveahnahn
    Contributor

    Tested apache-airflow-providers-snowflake==6.17.0rc1 for apache/airflow#69635 in Breeze (Python 3.10, Snowflake SQL API mocked with requests_mock). Works as expected.

  24. henry3260 commented on Sep 13, 2026

    @henry3260
    Contributor

    apache-airflow-providers-cncf-kubernetes==10.22.0rc1

  25. amoghrajesh commented on Sep 13, 2026

    @amoghrajesh
    Contributor

    Installed the RC and checked my changes, none of them were functional, it was all compat related.

    #72094
    #72140
    #72446

  26. aaron-y-chen commented on Sep 13, 2026

    @aaron-y-chen
    Contributor

    Verified #71350, it worked very well :)

  27. potiuk commented on Sep 13, 2026

    @potiuk
    Member

    Verified the 2026-09-09 RC (38 providers) end to end — all checks pass.

    Artifacts (dist/dev/airflow/providers/2026-09-09): folder complete (231 files = 38×6 + source trio; 77 .sha512 / 77 .asc, no double-extension leftovers); SHA512 77/77; GPG 77/77 good, all on the RM's key 1E7A857875E0EE49DB99E4431B17D6C5938CED00 (in KEYS); reproducible build 77/77 byte-identical — 76 wheels+sdists rebuilt from tag providers/2026-09-09 (209e34c5022a78c7691ac68a50f60d976242e17d), plus the source tarball; Apache RAT 0.18 — 0 unapproved / 0 unknown (10146 standard files, all AL2.0).

    Consistency: all 38 rc tags point at the wave commit; 38/38 pyproject.toml versions match their changelog tops; 38/38 PyPI rc pages resolve with both wheel and sdist.

    My own changes in this wave — ticked above. Each was confirmed present in the shipped wheel, not just at the tag, and its tests run green:

    PR Provider Tests
    #72646 akeyless 0.3.1 37 passed
    #72645, #72657, #72198, #72199 fab 3.9.0 281 passed
    #72207, #72205 keycloak 0.10.0 202 passed, 1 skipped

    For #72646 I also exercised the namespace guard from a clean venv containing only the RC wheel: a cross-team key under multi-team + team-scoped path is refused, while a flat key, use_team_secrets_path=False, an absent team name, and multi-team disabled all still resolve.

    One non-blocking observation (pre-existing, unchanged since the 2026-08-18 wave): the source tarball ships two OFL-1.1 web fonts at registry/public/fonts/{jetbrains-mono-latin,plus-jakarta-sans-latin}.woff2 while the root LICENSE is bare AL2.0 with no third-party section. Confirmed this wave that they are source-tarball only — no provider wheel contains them. A LICENSE follow-up, not a re-cut.


    Drafted-by: Claude Opus 5; reviewed by @potiuk before posting

  28. FrankYang0529 commented on Sep 14, 2026

    @FrankYang0529
    Member

    Tested following providers and all work as expected:

  29. vincbeck commented on Sep 14, 2026

    @vincbeck
    ContributorAuthor

    Thank you everyone. Providers are released.

    I invite everyone to help improve providers for the next release, a list of open issues can be found here.

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

Metadata

Metadata

Assignees

No one assigned

    Labels

    kind:metaHigh-level information important to the communitytesting statusStatus of testing releases

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions