Skip to content

Status of testing Providers that were prepared on August 06, 2026 #71246

Closed

Description

@potiuk

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.

Important

This is an expedited release. The 2026-08-01 wave was cancelled because it
carried the pandas < 3 cap from #70791, since reverted in #71100 and replaced
by pandas 3 support in #71103. Every provider is re-cut, so the voting window is
shorter than usual — please test promptly if you can.

Ticks already carried over from the cancelled wave's issue (#70953) mark code
that has not changed; please do not re-verify those. Only the unticked items
need attention.

keycloak is deliberately not in this wave — #70550 depends on middleware
that is still being fixed (#71077, #70981). It will follow in a later release.

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

Provider airbyte: 6.0.1rc2

Provider alibaba: 3.4.0rc2

Provider amazon: 9.34.0rc2

Provider anthropic: 0.2.1rc2

Provider apache.hive: 9.6.1rc2

Provider apache.kafka: 1.15.1rc2

Provider apache.livy: 4.6.0rc2

Provider apache.spark: 6.3.1rc2

Provider arangodb: 2.9.6rc2

Provider celery: 3.23.1rc2

Provider cncf.kubernetes: 10.21.0rc2

Provider cohere: 1.6.7rc2

Provider common.ai: 0.7.0rc3

Provider common.compat: 1.18.0rc2

Provider common.sql: 2.1.0rc2

Provider databricks: 7.18.1rc2

Provider dbt.cloud: 4.9.3rc2

Provider docker: 4.5.9rc2

Provider edge3: 4.3.0rc2

Provider elasticsearch: 6.9.0rc2

Provider fab: 3.8.0rc2

Provider git: 0.4.2rc2

Provider google: 22.3.0rc3

Provider hashicorp: 4.8.0rc2

Provider imap: 3.12.1rc2

Provider microsoft.azure: 14.1.0rc2

Provider neo4j: 3.12.1rc2

Provider openai: 1.8.2rc2

Provider openlineage: 2.20.0rc3

Provider opensearch: 1.12.0rc1

Provider papermill: 3.13.2rc2

Provider postgres: 7.0.1rc2

Provider sftp: 6.0.1rc2

Provider smtp: 3.0.3rc2

Provider snowflake: 6.16.0rc2

Provider ssh: 6.0.1rc2

Provider standard: 1.17.0rc2

Provider teradata: 3.6.2rc2

Provider weaviate: 3.4.1rc2

Provider yandex: 4.5.1rc2

All users involved in the PRs:
@shivaam @rjgoyln @guan404ming @gang-zh @Avcu @aeroyorch @bmanan7 @TimurRakhmatullin86 @shubhamraj-git @jroachgolf84 @yuseok89 @baha-bouali @ahilashsasidharan @Pandry @bramhanandlingala @kaxil @amoghrajesh @Andrushika @kacpermuda @harshhh817 @1fanwang @fallintoplace @Sdnsoumy @molcay @raphaelauv @noamst-monday @seanghaeli @fat-catTW @Samin061 @AlejandroMorgante @gopidesupavan @jason810496 @k-popov @SEPURI-SAI-KRISHNA @FrankYang0529 @Vamsi-klu @sduvvuri26 @mobuchowski @dkranchii @zozo123 @mitre88 @ColtenOuO @potiuk @AmoghAtreya @Lee-W @jx2lee @Eason09053360 @nikolauspschuetz @haseebmalik18 @daesung9511 @onlyarnav @olegkachur-e @takayoshi-makabe @steveahnahn @YAshhh29 @MannXo @shahar1 @dhkim1920 @ramitkataria @Aaryan123456679 @aaron-y-chen @jedcunningham @SameerMesiah97 @pierrejeambrun @Tegh25 @BasPH @justinpakzad @parkhojeong @michaelneely

Activity

  1. added
    kind:metaHigh-level information important to the community
    on Aug 6, 2026
  2. potiuk commented on Aug 6, 2026

    @potiuk
    MemberAuthor

    The issue body above mentions more contributors than GitHub renders as links — only the first 50 become real mentions, so the rest of you were never notified. Tagging you here so you see it.

    This is an expedited release: the 2026-08-01 wave was cancelled and every provider re-cut, so the voting window is shorter than usual. If you have a change in this wave, please test promptly.

    Items already ticked were carried over from #70953 and cover unchanged code — no need to re-verify those.

    @Tegh25 @stephen-bracken @yuseok89 @timestamp @k-popov @pierrejeambrun @VladaZakharova @Eason09053360 @uranusjr @Pandry @luke-hoffman1 @Vamsi-klu @radhwene @nikolauspschuetz @quantumlicht @molcay @parkhojeong @daesung9511 @SEPURI-SAI-KRISHNA @haseebmalik18 @olegkachur-e @BasPH @Samin061 @Andrushika @bmanan7 @jvstein @YAshhh29 @takayoshi-makabe @josix @mobuchowski @AutomationDev85 @ferruzzi @kacpermuda @gang-zh @Dev-iL @fallintoplace @shivaam @michaelneely @rjgoyln @AchimGaedkeLynker @raphaelauv @jroachgolf84 @surendarvarmas @Sdnsoumy


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

  3. onlyarnav commented on Aug 6, 2026

    @onlyarnav
    Member

    #71053 was an output rendering change conflictswith -> conflicts with
    Verified it, no testing required

  4. SEPURI-SAI-KRISHNA commented on Aug 6, 2026

    @SEPURI-SAI-KRISHNA
    Contributor

    Tested google 22.3.0rc3 for #70430 (Fail deferred Cloud Composer tasks when the GCP operation errors) — works as expected.

    Installed the RC from PyPI into a clean venv (apache-airflow-providers-google==22.3.0rc3, resolved against apache-airflow 3.3.0) and verified against the installed artifact rather than a source checkout.

    Unit tests — the trigger tests ship green against the RC:

    test_cloud_composer.py::TestCloudComposerExecutionTrigger::test_run_raises_when_operation_finished_with_error PASSED
    test_cloud_composer.py::TestCloudComposerExecutionTrigger::test_run_yields_event_when_operation_finished_without_error PASSED
    ... 6 passed
    

    Behavioural check with real LRO objects — the unit tests use a stand-in, so I also exercised the trigger against actual google.longrunning.operations_pb2.Operation values:

    Scenario Result
    done=True with error.message set raises AirflowException: Cloud Composer Environment error: quota exceeded
    done=True, no error yields {'operation_name': ..., 'operation_done': True}
    polls done=False twice, then fails raises after polling

    For contrast, the pre-fix loop on that same failed Operation returns {'operation_name': 'op', 'operation_done': True} — a success event for a failed operation, which is the bug. The RC no longer does this.

    I don't have a live Composer environment, so this is verification against the released artifact rather than a real environment creation/update failure.


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

  5. fallintoplace commented on Aug 6, 2026

    @fallintoplace
    Contributor

    Tested apache-airflow-providers-sftp==6.0.1rc2 for #70858.

    Installed the provider from PyPI in a clean Python 3.13 virtualenv with Airflow 3.3.0. The environment resolved Paramiko 5.0.0 and AsyncSSH 2.24.0.

    The documented private_key_passphrase extra was passed correctly to asyncssh.import_private_key. I also tested an encrypted private key against a temporary local AsyncSSH server and successfully opened an SFTP session.

    The existing passphrase extra behavior still works, and the shared Paramiko 5 RSA private-key validation also passed.

    No issues found.

  6. takayoshi-makabe commented on Aug 7, 2026

    @takayoshi-makabe
    Contributor

    Tested apache-airflow-providers-openai==1.8.2rc2 for #69506.

    Installed Airflow 3.3.0 + the RC into a clean venv from PyPI and exercised OpenAITriggerBatchOperator.execute_complete / validate_execute_complete_event / OpenAIBatchTrigger.run() directly (no live OpenAI API needed, this is pure trigger-event branching logic).

    As a control, I also installed the pre-fix 1.8.1 and confirmed all three bugs actually reproduce there:

    Case 1.8.1 (pre-fix) 1.8.2rc2
    status="cancelled" treated as SUCCESS, returns batch_id raises OpenAIBatchJobException
    event=None crashes with raw TypeError: 'NoneType' object is not subscriptable raises OpenAITriggerEventError
    unknown status (e.g. "expired") silently treated as SUCCESS raises OpenAITriggerEventError
    status="success" / "error" works still works

    Also confirmed OpenAIBatchTrigger.run() now yields exactly one terminal event (no spurious duplicate error event after a terminal event).
    All checks pass on the RC. No issues found.


    Drafted-by: Claude Code; reviewed by @takayoshi-makabe before posting

  7. seanghaeli commented on Aug 7, 2026

    @seanghaeli
    Contributor

    Verified #70206

  8. k-popov commented on Aug 7, 2026

    @k-popov
    Contributor

    Verified #70790

  9. radhwene commented on Aug 7, 2026

    @radhwene
    Contributor

    Tested apache-airflow-providers-google==22.3.0rc3 for #68151 (CloudSQLNoOperationInProgressSensor).

    I installed the RC from PyPI in a clean Python 3.12 environment with Airflow 3.3.0. pip check is clean, including the RC dependencies on common-sql and common-compat.

    I also compared it with Google provider 19.5.0 to confirm that the new sensor, trigger, status constant and CloudSQLHook.list_operations() are all present only in the RC.

    For poke(), I checked the main paths:

    • RUNNING or PENDING operation → keeps waiting
    • only DONE operations, or no operations → succeeds
    • mixed DONE and RUNNING → keeps waiting
    • operation without a status → does not block
    • HTTP 403/404 → raises CloudSQLOperationError
    • HTTP 500 → re-raises the original HttpError

    I also confirmed that the existing Cloud SQL import and export operators still import correctly.

    I did not run a real parallel workload against Cloud SQL, so this validates the released artifact and its synchronous sensor behaviour, not the remaining timing window under live concurrency.

    No issues found in the scope tested.

    ⸻

    Drafted with Claude ; reviewed by @radhwene before posting.

  10. michaelneely commented on Aug 7, 2026

    @michaelneely
    Contributor

    Verified #67848

    The result of a SnowflakeSqlApiOperator is now correctly displayed:

    [2026-08-07 08:49:33] INFO - Snowflake SQL GET statements status API response: {'resultSetMetaData': {'numRows': 1, 'format': 'jsonv2', 'partitionInfo': [{'rowCount': 1, 'uncompressedSize': 13}], 'rowType': [{'name': 'CURRENT_VERSION()', 'database': '', 'schema': '', 'table': '', 'scale': None, 'byteLength': 134217728, 'nullable': True, 'precision': None, 'collation': None, 'length': 134217728, 'type': 'text'}]}, 'data': [['10.27.100']], 'code': '090001', 'statementStatusUrl': '/api/v2/statements/01c63a11-0003-ce9d-0000-2405aa0ac8c6?requestId=484ca2aa-2f44-4e29-967c-bb4dd064ad70', 'requestId': '484ca2aa-2f44-4e29-967c-bb4dd064ad70', 'sqlState': '00000', 'statementHandle': '01c63a11-0003-ce9d-0000-2405aa0ac8c6', 'message': 'Statement executed successfully.', 'createdOn': 1786092573014}

  11. YAshhh29 commented on Aug 7, 2026

    @YAshhh29
    Contributor

    Tested apache-airflow-providers-openai==1.8.2rc2 for #69534.

    I installed the PyPI wheel in a clean Python 3.10.20 environment with
    Airflow 3.1.3, OpenAI provider 1.8.2rc2, and OpenAI SDK 2.53.0.
    pip check is clean. The wheel SHA-256 is
    c7b9e56d38b3edd914780e11a94e048c7905dfaf70999b7c2c1365d89c63f570,
    matching the PyPI artifact.

    For #69534, I verified that:

    • OpenAITriggerBatchOperator passes timeout to OpenAIBatchTrigger.
    • The preferred timeout and legacy end_time forms both serialize correctly.
    • Supplying both arguments, or neither argument, is rejected.
    • With monotonic time advancing 100 -> 101 -> 106, the trigger reports
      timeout after six elapsed seconds.
    • A simulated wall-clock jump is never read by the RC timeout path.
    • As a control, provider 1.8.1 reads wall time and times out early after
      the same simulated jump.

    I also confirmed that the dependency change from #69408 remains present:
    the RC metadata requires plain openai>=2.37.0 without the datalib
    extra. The clean environment contains no numpy, pandas, or
    pandas-stubs. This metadata change was already present in provider 1.8.1,
    so this part is regression verification rather than an RC-versus-1.8.1
    difference.

    RC artifact checks: 9 passed.
    Pre-fix comparison: 1 passed.

    I used the clean-virtualenv contributor verification method. No live
    OpenAI API call was made; this validates the published artifact's metadata,
    serialization, validation, operator handoff, and timeout behavior.

    No issues found in the tested scope.


    Drafted-by: GitHub Copilot; reviewed by @YAshhh29 before posting

  12. Eason09053360 commented on Aug 7, 2026

    @Eason09053360
    Contributor

    Verified my three items on this wave, all against the RC wheels from PyPI
    installed into the official apache/airflow:3.1.3-python3.10 image

    All three look good to me :)


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

  13. molcay commented on Aug 7, 2026

    @molcay
    Contributor

    Thank you very much @potiuk for the RC.

    From google provider perspective, we did NOT find any regression.

    We are giving +1.

  14. potiuk commented on Aug 7, 2026

    @potiuk
    MemberAuthor

    google 22.3.0rc3 is removed from the 2026-08-06 wave

    The google provider has been pulled from this wave following a binding -1 on the
    vote thread: apache-airflow-providers-google==22.3.0rc3 cannot be installed on
    Python 3.14.

    Root cause is upstream, not in the provider code. google-cloud-aiplatform caps
    its evaluation extra at litellm>=1.83.7,<1.86.0, and no litellm in that range
    installs on Python 3.14, so pip install apache-airflow-providers-google fails
    with ResolutionImpossible despite the provider advertising
    requires_python >= 3.10. It affects the already-released 22.2.x line too.

    What this means for this issue

    • Nothing else in the wave is affected — the other 45 providers are unchanged,
      and testing/verification on them continues to count.
    • The google rc3 artifacts stay in the dev dist folder for now; they simply will
      not be promoted when this wave is published.
    • The google verifications already recorded here carry over — they were done
      against code that is unchanged by Workaround bug in google-claude-aiplatform evaluation extra (Python 3… #71273, which only touches dependency
      metadata. Please do not re-verify them.

    What happens to google

    google will be re-cut as 22.3.0rc4 in a separate google-only wave with release
    preparation date 2026-08-08, carrying #71273 on top of the same code. That wave
    gets its own testing status issue, and the ticks from here will be carried over to
    it.


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

  15. dhkim1920 commented on Aug 8, 2026

    @dhkim1920
    Contributor

    Verified #68716
    apache-airflow-providers-cncf-kubernetes==10.21.0rc2 with Airflow 3.3.0 on Kind Kubernetes v1.30.13.

    I re-ran the RBAC scenarios covered by #68716 using restricted ServiceAccounts, including Pod and Job operators,
    deferrable Jobs, KubernetesExecutor with multi-namespace mode, cleanup, SparkApplication, generic custom resources,
    and Kueue installation/Jobs.

    All expected operations succeeded, while out-of-scope permissions were denied. I found no rc2-specific issues, and
    #40210 appears addressed from the documented RBAC perspective.


    Drafted-by: Codex (GPT-5); reviewed by @dhkim1920 before posting

  16. fat-catTW commented on Aug 8, 2026

    @fat-catTW
    Contributor

    Verified the following Amazon provider changes with apache-airflow-providers-amazon==9.34.0rc2 on Airflow 3.3.0 in clean venvs. I also compared each relevant behavior with apache-airflow-providers-amazon==9.33.0.

    #70445: AwsToAwsBaseOperator destination connection fallback
    Checked dest_aws_conn_id fallback behavior when dest_aws_conn_id is omitted:

    • previous release 9.33.0: after source_aws_conn_id changes from 'source_before_render' to 'source_after_render', dest_aws_conn_id still returns 'source_before_render'
    • RC 9.34.0rc2: dest_aws_conn_id follows the updated source and returns 'source_after_render'

    Also checked that explicit dest_aws_conn_id=None and templated dest_aws_conn_id are preserved during operator construction.

    #70440: templated validation fields in AppFlow operators
    Checked AppflowRunDailyOperator with templated source, source_field, and filter_date.

    Previous release 9.33.0 rejects the operator during construction:
    Source {{ params.source }} is not supported for AppflowRunDailyOperator!

    RC 9.34.0rc2 allows construction, renders the fields, validates after rendering, and executes the patched run path with:

    • source='salesforce'
    • source_field='CreatedDate'
    • filter_date='2022-05-26T00:00:00+00:00

    #70464: deferred ECS logs region selection
    Checked EcsRunTaskOperator.execute_complete() when region_name='task-region' and awslogs_region='logs-region'.

    Previous release 9.33.0 calls AwsLogsHook with region_name='task-region'.

    RC 9.34.0rc2 calls AwsLogsHook with region_name='logs-region' and returns the expected log output.

    Result: all three work as expected.


    Drafted-by: Codex (GPT-5); reviewed by @fat-catTW before posting

  17. potiuk commented on Aug 9, 2026

    @potiuk
    MemberAuthor

    The 2026-08-06 wave has been released. 44 providers are now available on PyPI, in SVN and their documentation is live at https://airflow.apache.org/docs/

    Thank you all for testing and verifying the release candidates!

    Two providers were excluded from this wave and re-cut in the 2026-08-08 wave:

    Testing for those two continues in #71321.


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

  18. shivaam commented on Aug 9, 2026

    @shivaam
    Contributor

    Tested four changes that were not already reported in the issue comments, using exact PyPI RC artifacts in clean venvs with Airflow 3.3.0; all passed:

    I also ran a real Airflow 3.3.0 Breeze deployment with the exact RC artifacts installed from PyPI and mounted provider sources disabled. A focused DAG parsed without import errors and completed successfully through the scheduler and LocalExecutor: the artifact-identity gate and the behavior tasks for the four items above passed. The API health check reported the metadata DB, scheduler, triggerer, and DAG processor healthy. No live external provider services or credentials were used.

    No issues found.


    Drafted-by: OpenAI Codex (GPT-5.6); reviewed by @shivaam before posting

  19. Vamsi-klu commented on Aug 22, 2026

    @Vamsi-klu
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

    area:providerskind: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