Skip to content

Status of testing Providers that were prepared on September 22, 2026 #73658

Closed
Closed
Status of testing Providers that were prepared on September 22, 2026#73658
Labels
kind:metaHigh-level information important to the communitytesting statusStatus of testing releases

Description

@shahar1
shahar1
opened on Sep 24, 2026

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 airbyte: 6.1.0rc1

Provider alibaba: 3.5.0rc1

Provider amazon: 9.37.0rc1

Provider anthropic: 1.1.0rc1

Provider apache.beam: 6.3.0rc1

Provider apache.cassandra: 3.10.0rc1

Provider apache.druid: 4.6.0rc1

Provider apache.flink: 1.9.0rc1

Provider apache.hdfs: 4.14.0rc1

Provider apache.hive: 9.7.0rc1

Provider apache.kylin: 3.11.0rc1

Provider apache.livy: 4.6.2rc1

Provider apache.pig: 4.9.0rc1

Provider apache.tinkerpop: 1.2.0rc1

Provider apprise: 2.4.0rc1

Provider arangodb: 2.10.0rc1

Provider asana: 2.12.0rc1

Provider atlassian.jira: 3.4.0rc1

Provider celery: 3.24.1rc1

Provider cloudant: 4.3.6rc1

Provider cncf.kubernetes: 10.23.0rc1

Provider cohere: 1.8.0rc1

Provider common.ai: 0.10.0rc1

Provider common.compat: 1.20.0rc1

Provider common.io: 1.10.0rc1

Provider common.messaging: 2.1.1rc1

Provider common.sql: 2.2.0rc1

Provider databricks: 7.21.0rc1

Provider datadog: 3.11.0rc1

Provider dbt.cloud: 4.10.0rc1

Provider dingding: 3.10.0rc1

Provider docker: 4.6.0rc1

Provider duckdb: 0.1.0rc1 🎉 New provider

Note: This is a new provider, so the PRs below are collected from the git history of the provider's sources rather than from a changelog diff. The list may therefore include bootstrap and development commits (e.g. release-preparation commits) that are not user-facing changes.

Provider edge3: 5.0.0rc1

Provider exasol: 4.11.0rc1

Provider fab: 3.10.0rc1

Provider ftp: 3.16.0rc1

Provider git: 1.0.0rc1

Provider github: 2.12.0rc1

Provider google: 22.6.0rc1

Provider grpc: 3.10.0rc1

Provider http: 6.2.0rc1

Provider imap: 3.13.0rc1

Provider influxdb: 2.12.0rc1

Provider keycloak: 0.11.0rc1

Provider microsoft.azure: 15.2.0rc1

Provider microsoft.psrp: 4.0.0rc1

Provider microsoft.winrm: 3.15.0rc1

Provider mongo: 5.5.0rc1

Provider mysql: 6.7.0rc1

Provider neo4j: 3.13.0rc1

Provider openai: 2.0.0rc1

Provider openlineage: 2.20.2rc1

(List continues in the first comment — the full list exceeds GitHub's issue body limit.)

Activity

  1. shahar1 commented on Sep 24, 2026

    @shahar1
    shahar1
    on Sep 24, 2026
    ContributorAuthor

    Provider opensearch: 1.13.0rc1

    Provider opsgenie: 5.11.0rc1

    Provider oracle: 4.7.0rc1

    Provider pagerduty: 5.3.0rc1

    Provider pinecone: 2.5.0rc1

    Provider postgres: 7.1.0rc1

    Provider presto: 5.13.0rc1

    Provider qdrant: 1.6.0rc1

    Provider redis: 4.7.0rc1

    Provider salesforce: 5.15.0rc1

    Provider samba: 4.14.0rc1

    Provider segment: 3.10.0rc1

    Provider sftp: 6.1.0rc1

    Provider slack: 9.11.0rc1

    Provider smtp: 3.1.0rc1

    Provider snowflake: 6.18.0rc1

    Provider ssh: 6.1.0rc1

    Provider standard: 1.20.0rc1

    Provider tableau: 5.7.0rc1

    Provider telegram: 4.10.0rc1

    Provider teradata: 3.7.0rc1

    Provider trino: 6.7.0rc1

    Provider weaviate: 3.5.0rc1

    Provider yandex: 4.6.0rc1

    All users involved in the PRs:
    @ColtenOuO @YAshhh29 @jacobcbeaudin @jakezwang @jroachgolf84 @Eason09053360 @SIBTAIN-ASAD @anxkhn @eladkal @yuseok89 @SEPURI-SAI-KRISHNA @Aaryan123456679 @gtxu @bingqin2 @namanjain24-sudo @jeff3071 @thc1006 @FrankYang0529 @keemgdeok @shoemoney @aaron-y-chen @Jie211 @moomindani @wolvery @yamakazushi @dabla @stegololz @developer-rpai @subhramit @saadbelgi @baha-bouali @amoghrajesh @br413 @sehajsandhu123 @Zeeshan-Chaudhry @potiuk @pankajkoti @VladaZakharova @pierrejeambrun @alant94 @Samin061 @mitre88 @arnoldmr01 @shahar1 @14041999ai @anishgirianish @Lee-W @justinpakzad @vitorantoniazzi @kacpermuda @nikoki @Lothnic @kaxil @ucaeon @DhanushAnegondi @LE0-Lin @Andrushika @ylv01 @SameerMesiah97 @KingLizard1020 @osintalex @rjgoyln @guan404ming @mobuchowski @shashank-iitbhu @dlactin @TheoLauw @auyua9 @ozemin @sgoel2be24-cyber @Kunal8954 @yuyua9 @o-nikolas @ShousenZHANG @pankajastro @keith991001 @vincbeck

  2. shahar1
    added
    kind:metaHigh-level information important to the community
    testing statusStatus of testing releases
    on Sep 24, 2026

  3. shoemoney commented on Sep 24, 2026

    @shoemoney
    shoemoney
    on Sep 24, 2026
    Contributor

    Verified #72068 against the PyPI-installed apache-airflow-providers-cncf-kubernetes==10.23.0rc1 with Airflow 3.3.2 and Python 3.12.14.

    All 13 focused behavior checks passed, plus an installed-version/import-path check: successful XCom survives sidecar command and API 403/404 kill failures; strict mode propagates those failures; the Job path fails before completion polling and still cleans up; read errors remain visible; normal extraction still succeeds.

    Kubernetes API boundaries were mocked. I did not run a live-cluster test or validate the provider release as a whole.

    Drafted-by: Codex (GPT-6) (no human review before posting)

  4. namanjain24-sudo commented on Sep 24, 2026

    @namanjain24-sudo
    namanjain24-sudo
    on Sep 24, 2026
    Contributor

    sftp 6.1.0rc1 includes the fix for #73584 (#73593 — SFTPHookAsync no longer lets a connection's known_hosts extra override an explicit constructor path).

    Verified:

    • The fix commit (7dfa256) is an ancestor of the release-prepare commit that bumped providers/sftp to 6.1.0, so it's in this RC.
    • The regression test added by the PR, test_explicit_known_hosts_constructor_arg_is_not_overridden_by_connection_extra, passes against that commit.

    Drafted-by: Claude Code (Sonnet 5); reviewed by @namanjain24-sudo before posting

  5. ucaeon commented on Sep 24, 2026

    @ucaeon
    ucaeon
    on Sep 24, 2026
    Contributor

    Verified #72820 using the PyPI-installed apache-airflow-providers-fab==3.10.0rc1 with Airflow 3.3.2, Python 3.10.21, and SQLite in Breeze. Confirmed that FAB was imported from the installed package rather than the local source checkout.

    All 10 behavior checks passed, covering:

    • Configured role and permission creation during API server startup.
    • Restart without duplicate roles, and preservation of manually modified permissions on existing roles.
    • Startup respecting update_fab_perms=False, while explicit airflow sync-perm still creates configured roles.
    • Rejection of unknown action/resource names and invalid configuration structures without partial role creation, plus malformed JSON rejection.
    • The normal FAB Website read permission for roles configured with an empty permission list.

    The API server was started and restarted, and role state was checked directly in the test database. Manual permission changes were simulated through database updates. Verification was limited to the startup and CLI behavior described above, using SQLite.

    Drafted-by: Codex (GPT-6) (reviewed by @ucaeon before posting)

  6. yamakazushi commented on Sep 24, 2026

    @yamakazushi
    yamakazushi
    on Sep 24, 2026
    Contributor

    Verified amazon 9.37.0rc1 for #72622(Support code packages in MWAA Serverless workflow operators).

    Installed the RC from PyPI and exercised both operators against the real API in ap-northeast-1.

    MwaaServerlessCreateWorkflowOperator with code set — CreateWorkflow accepted it, and GetWorkflow returned it unchanged:

    "Code": {"S3Location": {"Bucket": "...", "ObjectKey": "code/code_bundle.zip"}},
"CodeSnapshottedAt": "2026-09-24T14:25:14.158046+00:00",
"WorkflowVersion": "a2f35...",
"WorkflowStatus": "READY"

    MwaaServerlessUpdateWorkflowOperator with a nested VersionId pinned to a non-latest S3 object version — UpdateWorkflow passed it through, and GetWorkflow returned that exact version id rather than the latest one:

    "Code": {"S3Location": {
    "Bucket": "...",
    "ObjectKey": "code/code_bundle.zip",
    "VersionId": "TYSsm..."
}},
"CodeSnapshottedAt": "2026-09-24T14:33:15.258539+00:00",
"WorkflowVersion": "6b71c..."

    WorkflowVersion and CodeSnapshottedAt both changed, so the update took effect and the service re-snapshotted the code at the pinned version.

    Works as expected.

  7. rjgoyln commented on Sep 24, 2026

    @rjgoyln
    rjgoyln
    on Sep 24, 2026
    Contributor

    Verified my 10 items against the PyPI-installed RCs — apache.beam 6.3.0rc1, cncf.kubernetes 10.23.0rc1, databricks 7.21.0rc1, fab 3.10.0rc1, git 1.0.0rc1, google 22.6.0rc1 — with Airflow 3.3.2 and Python 3.12.3 in fresh virtualenvs, each check asserting the provider was imported from site-packages. Each PR's merge commit is also an ancestor of its provider's RC tag.

    61 behavior checks passed:

    Every check that asserts fixed behaviour fails against the previous release of the same provider (10.22.0 / 7.20.0 / 3.9.0 / 0.5.0 / 22.5.0 / 6.2.4).

    Cloud and Kubernetes API boundaries were mocked. Not covered: a live MySQL run of the FAB revision (no Docker available here, so only the offline script and the live-bind code path were exercised), an HTTPS clone against a real git server, and the Airflow 2 only trigger branches in #72697, which are gated out on 3.3.2 and were checked by source inspection.

    Drafted-by: Claude Code (Opus 5) (no human review before posting)

  8. sgoel2be24-cyber commented on Sep 24, 2026

    @sgoel2be24-cyber
    sgoel2be24-cyber
    on Sep 24, 2026
    Contributor

    Verified #73323 against the PyPI-installed apache-airflow-providers-amazon==9.37.0rc1 with Airflow 3.3.2 and Python 3.12.13.

    I drove EmrServerlessDeleteApplicationOperator through its full deferral lifecycle, resuming each deferral with a success event as the triggerer would. The EMR Serverless client was mocked.

    • deferrable=True: stop → delete_stopped_application → DeleteApplication called once → EmrServerlessDeleteApplicationTrigger → done.
    • deferrable=True, force_stop=True: cancel jobs → stop → delete, with DeleteApplication called once.
    • A stop-trigger error event fails the task without calling DeleteApplication.
    • Regressions: deferrable=False still deletes, and EmrServerlessStopApplicationOperator still resumes at execute_complete without deleting.

    For comparison, on 9.36.0 the deferrable runs finish with zero DeleteApplication calls while logging "deleted successfully", which is the #72123 bug. On the RC, #73323 is working as expected.

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

  9. keemgdeok commented on Sep 24, 2026

    @keemgdeok
    keemgdeok
    on Sep 24, 2026
    Contributor

    Verified #72883 against the PyPI-installed apache-airflow-providers-redis==4.7.0rc1 with Airflow 3.3.2 and Python 3.12.12. RedisPublishOperator rendered a templated redis_conn_id, and execute() passed the rendered ID to RedisHook. The hook was mocked; I did not test against a live Redis server.

    Drafted-by: Codex (GPT-6); reviewed by @keemgdeok before posting

  10. aaron-y-chen commented on Sep 24, 2026

    @aaron-y-chen
    aaron-y-chen
    on Sep 24, 2026
    Contributor

    My parts (#71135 and #73588) are working well on my local machine :)

  11. subhramit commented on Sep 24, 2026

    @subhramit
    subhramit
    on Sep 24, 2026
    Contributor

    For Provider influxdb: 2.12.0rc1
    #71976

    Was a bit short on time so I let my agent test it. It works as expected :)
    (Local, macOS Tahoe 26.2)
    Image

    cc @shahar1

  12. SEPURI-SAI-KRISHNA commented on Sep 24, 2026

    @SEPURI-SAI-KRISHNA
    SEPURI-SAI-KRISHNA
    on Sep 24, 2026
    Contributor

    Tested apache-airflow-providers-amazon==9.37.0rc1 for Build deferred AWS hooks from the operator's own settings (#72171). Works as expected, no regressions found.

    Environment: clean virtualenv on Python 3.11, installed from PyPI, apache-airflow 3.3.2, apache-airflow-task-sdk 1.3.2, boto3 1.43.101. No AWS account involved, since everything below is observable before the first API call.

    I ran the same checks against 9.36.0 to confirm they actually depend on this change rather than passing either way.

    1. The operator's settings reach the hook the triggerer builds. Using BedrockKnowledgeBaseActiveSensor in deferrable mode with region_name="eu-west-3", verify=False and botocore_config=Config(read_timeout=77, retries={"max_attempts": 9}), I captured the TaskDeferred and built the hook from the trigger it carried.

    9.36.0 9.37.0rc1
    region_name on the trigger absent eu-west-3
    verify on the trigger absent False
    botocore_config on the trigger absent passed through
    hook.region_name None eu-west-3
    hook._verify None False
    hook._config.read_timeout None 77
    hook._config.retries None {'max_attempts': 9}

    On 9.36.0 the operator is configured for eu-west-3 with a custom timeout and the deferred half still talks to AWS with boto3 defaults. On the release candidate it does not.

    2. The same holds across the provider, not just that one sensor. I walked every self.defer(trigger=...) site in the installed wheel and confirmed that the deferrals this change covers now hand region_name, verify and botocore_config to the trigger. The identical sweep against 9.36.0 shows those same sites passing none of them, so the change is load bearing and consistent rather than limited to the paths with unit tests.

    3. The import time guard on AwsBaseWaiterTrigger is live. A subclass that declares neither aws_hook_class nor its own hook() is rejected at class creation with Class attribute 'NoHook.aws_hook_class' should be set, or NoHook.hook() overridden., and one whose aws_hook_class is not an AwsGenericHook subclass is rejected as well. Subclasses that declare either are accepted. A trigger that cannot build a hook therefore fails where it is defined rather than later in the triggerer, out of sight of the task that deferred.

    Drafted-by: Claude Opus 5; reviewed by @SEPURI-SAI-KRISHNA before posting

  13. jacobcbeaudin commented on Sep 24, 2026

    @jacobcbeaudin
    jacobcbeaudin
    on Sep 24, 2026
    Contributor

    Verified #63470 (SnowflakeNotebookOperator) against the PyPI-installed
    apache-airflow-providers-snowflake==6.18.0rc1 with Airflow 3.1.8 and Python 3.11
    (Astro Runtime 3.1-15, LocalExecutor), against a live Snowflake account with key-pair auth.
    Nothing was mocked.

    • deferrable=False: EXECUTE NOTEBOOK submitted through the SQL API, polled to completion, task succeeded.
    • deferrable=True: task deferred, the trigger polled to completion, task resumed and succeeded.
    • notebook_parameters: two templated string parameters reached the notebook in sys.argv
      (the notebook wrote them to a table, and I checked the rows).
    • Failure: a notebook that raises makes the task fail in both modes, with the notebook's
      error message in the task log.
    • Templated notebook and snowflake_conn_id rendered correctly.

    Works as expected ✅

    Doc note for a possible follow-up (not a blocker): inside a Snowflake Notebook,
    sys.argv[0] is the first parameter (there is no script name), and with no parameters
    sys.argv == [''].

    Drafted-by: Claude Code (Opus 5.5); reviewed by @jacobcbeaudin before posting

  14. potiuk commented on Sep 24, 2026

    @potiuk
    potiuk
    on Sep 24, 2026
    Member

    Tested my changes with the RC distributions installed from PyPI wheels (Airflow 3.3.2 + all 78 providers of this wave) - all good:

    Also verified two changes that are in this wave but have no section in this issue:

    Drafted-by: Claude Code (Opus 5.5); reviewed by @potiuk before posting

  15. 15 remaining items

  16. FrankYang0529 commented on Sep 28, 2026

    @FrankYang0529
    FrankYang0529
    on Sep 28, 2026
    Member

    Tested following providers and all work as expected:

  17. raphaelauv commented on Sep 28, 2026

    @raphaelauv
    raphaelauv
    on Sep 28, 2026
    Contributor

    hey @shahar1

    look like this this PR #72659 should be rename in the changelog to ->

    disable start_from_trigger when using a templated `target_time`

  18. stegololz commented on Sep 28, 2026

    @stegololz
    stegololz
    on Sep 28, 2026
    Contributor

    @shahar1 tested sftp 6.1.0rc1, mainly #73288 and #72336. Both work as advertised.

    Method: real transfers against a local asyncssh SFTP server, with the rc1 wheel from PyPI, on Airflow 3.3.2 (asyncssh 2.24.0, paramiko 5.0.0, Python 3.13) and, for backwards compatibility, on 2.11.2, 3.0.6, 3.1.8 and 3.2.2.

    • Add deferrable mode to SFTPOperator #72336: SFTPOperator(deferrable=True) defers to SFTPTransferTrigger, the trigger re-instantiated from serialize() completes PUT, GET and DELETE for single files, lists with concurrency=2 and directory trees, create_intermediate_dirs works, a missing GET source yields an error event that execute_complete turns into AirflowException, and a missing connection id raises ValueError. The synchronous path through the new SFTPHook.transfer() still does PUT, GET and DELETE. Same results on all five Airflow versions.
    • Keep pooled SFTP connection on application-level SFTP errors #73288: five consecutive SFTPNoSuchFile on one SFTPClientPool reuse a single SSH connection; SFTPConnectionLost and a non-SFTPError still drop it. Same on all five versions.
    • The pools and triggers unit test modules from the tag pass standalone on all five versions (46 tests).

    Drafted-by: Claude Code (Fable 5.1); reviewed by @stegololz before posting

  19. Lee-W commented on Sep 28, 2026

    @Lee-W
    Lee-W
    on Sep 28, 2026
    Member

    Verifeid #72156, #73053, #71734, #72853, #73381, #73452, #73578, #73366, #73367, #73450, #70628. (also checked the list above)

  20. shahar1 commented on Sep 28, 2026

    @shahar1
    shahar1
    on Sep 28, 2026
    ContributorAuthor

    hey @shahar1

    look like this this PR #72659 should be rename in the changelog to ->

    disable start_from_trigger when using a templated `target_time`

    Thanks! I'll figure out how to fix it in the docs before the actual release.

  21. FrankYang0529 commented on Sep 28, 2026

    @FrankYang0529
    FrankYang0529
    on Sep 28, 2026
    Member

    edge3 5.0.0rc1 has a regression from my PR #72048, so I'd hold edge3 for an rc2:

    • Make EdgeExecutor respect [core] parallelism #72048: [core] parallelism now takes effect. With parallelism = 3 and six parallel tasks, the RC queues three task instances and leaves three scheduled, while 4.3.2 queues all six. But when the scheduler restarts while Edge task instances from the previous scheduler are still queued or running, the new scheduler crashes on startup with DetachedInstanceError, and every later restart crashes the same way. The upgrade path hits it too: after a scheduler running 4.3.2 queues some Edge tasks and stops, the first scheduler start after upgrading to 5.0.0rc1 crashes the same way. I reproduced both cases with the RC from PyPI on Airflow 3.3.2

    The fix is in #73832.

  22. Lee-W commented on Sep 28, 2026

    @Lee-W
    Lee-W
    on Sep 28, 2026
    Member

    @shahar1 The changelog in common.ai provider is technically right.

    Add branch_descriptions to LLMBranchOperator so the model reads what each branch means (#73639)

    but it can be misleading as it's changed into branches later on (within 0.10.0rc1)

    WDYT?

  23. shahar1 commented on Sep 28, 2026

    @shahar1
    shahar1
    on Sep 28, 2026
    ContributorAuthor

    @shahar1 The changelog in common.ai provider is technically right.

    Add branch_descriptions to LLMBranchOperator so the model reads what each branch means (#73639)

    but it can be misleading as it's changed into branches later on (within 0.10.0rc1)

    WDYT?

    Merged your fix :)

  24. shahar1 commented on Sep 28, 2026

    @shahar1
    shahar1
    on Sep 28, 2026
    ContributorAuthor

    Tested all commits in the standard provider

  25. kaxil commented on Sep 28, 2026

    @kaxil
    kaxil
    on Sep 28, 2026
    Member

    Verified common.ai 0.10.0rc1 from the PyPI wheel on Airflow 3.3.2 (Python 3.12), plus Airflow 3.0.6 for the version gates, with live runs against Claude, TypeSafe Jev and Modal sandboxes. Everything below works as described in the PRs:

    One non-blocking follow-up, which I'll open a PR for: #73273 updated the LLMSchemaCompareOperator docs and example to use a DataSourceConfig with only conn_id + table_name, which needs common.sql 2.2.0, while the sql extra still allows common.sql 2.1.1. #73273 and #73370 themselves ship in common.sql 2.2.0rc1, so I didn't test them here.

    +1 for common.ai 0.10.0rc1.

  26. shahar1 commented on Sep 29, 2026

    @shahar1
    shahar1
    on Sep 29, 2026
    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.

  27. shahar1
    closed this as completedon Sep 29, 2026

  28. raphaelauv commented on Sep 29, 2026

    @raphaelauv
    raphaelauv
    on Sep 29, 2026
    Contributor

    Hey @shahar1 , I do not see kubernetes 10.23.0 in pypi

    https://pypi.org/project/apache-airflow-providers-cncf-kubernetes/#history

  29. moomindani commented on Sep 30, 2026

    @moomindani
    moomindani
    on Sep 30, 2026
    Contributor

    #72505 works as expected on the databricks 7.21.0 release candidate (Airflow 3.3.2, live workspace): environments/trigger round-trip through DatabricksCreateJobsOperator for both file_arrival and periodic, and DatabricksSubmitRunOperator passes environments to runs/submit.

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

  30. shahar1 commented on Sep 30, 2026

    @shahar1
    shahar1
    on Sep 30, 2026
    ContributorAuthor

    Hey @shahar1 , I do not see kubernetes 10.23.0 in pypi

    https://pypi.org/project/apache-airflow-providers-cncf-kubernetes/#history

    It had been excluded from the release due to a regression, I've notified about that in the dev list.

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