Status of testing Providers that were prepared on August 18, 2026 #71847

Activity

1. hussein-awala

   added

   kind:metaHigh-level information important to the communityHigh-level information important to the community

   testing statusStatus of testing releasesStatus of testing releases

   on Aug 19, 2026
2. dosubot

   added

   area:providers

   kind:documentation

   on Aug 19, 2026
3. stephen-bracken commented on Aug 19, 2026

   

   stephen-bracken

   on Aug 19, 2026

   Last edited by stephen-bracken

   Contributor

   More actions

   keycloak 0.9.0rc2

   Keycloak JWT changes #70800 #71077 #71506 and #70550 all working on v3.3.0, Keycloak cookies are created and read correctly.

   
4. MannXo commented on Aug 19, 2026

   

   MannXo

   on Aug 19, 2026

   Contributor

   More actions

   Verified the fab 3.8.1rc1 item for #71624 (docs fix for #71569).

   Setup: Airflow 3.3.1 with apache-airflow-providers-fab==3.8.1rc1 on Python 3.12, installed against the 3.3.1 constraints file with the fab pin removed so the RC could go in without dragging pre-release builds of SQLAlchemy and friends along. FabAuthManager enabled, AUTH_TYPE = AUTH_OAUTH, one google entry in OAUTH_PROVIDERS with dummy credentials.

   What the running RC does:

   1. Starting the flow at /auth/login/google redirects to the IdP with redirect_uri=http%3A%2F%2Flocalhost%3A8080%2Fauth%2Foauth-authorized%2Fgoogle. That is exactly the path the corrected docs now tell you to register.
   2. GET /auth/oauth-authorized/google is a real route (302).
   3. GET /oauth-authorized/google, the path the docs gave before, returns 200 with the UI shell, byte-identical to what a nonsense path returns, because the SPA catch-all serves it. So the old instructions never failed loudly: the IdP redirected to a page that looked fine and the login simply never completed.

   The corrected text is present at the providers-fab/3.8.1rc1 tag.

   Separately, while setting this up I hit a second problem in the same guide, not related to this release. Step 1 of the SSO page still says to set auth_manager in the [webserver] section. On 3.3.1 that key is silently ignored, you stay on SimpleAuthManager, and no warning is emitted; the option lives in [core]. I will send a follow-up PR for it.

   I only tested my own item, not the rest of the fab list.
5. coleheflin commented on Aug 19, 2026

   

   coleheflin

   on Aug 19, 2026

   Contributor

   More actions

   Verified both items I'm tagged on:

   git 0.4.3rc1 — #69735 (Document commit SHA support for GitDagBundle.tracking_ref)
   Confirmed the rendered docs at providers/git/docs/bundles/index.rst correctly describe branch/tag/full-SHA support for tracking_ref, the static-ref no-refresh caveat, and the promote-vs-rollback asymmetry (tracked in #71388). Ran the bundle test suite, all SHA checkout/promotion/rollback tests pass.

   keycloak 0.9.0rc2 — #71572 (Grant team Op role access to team Dags)
   Confirmed Op-{team} now includes Dag:{team} in both the permission-creation and permission-attach code paths. Full test_commands.py suite passes (16/16).

   Both addressed. ✅
6. SEPURI-SAI-KRISHNA commented on Aug 20, 2026

   

   SEPURI-SAI-KRISHNA

   on Aug 20, 2026

   Contributor

   More actions

   Verified the microsoft.azure 15.0.0rc1 item for #71649 (Keep MSGraph request configuration across paginated pages).

   Setup: Airflow 3.3.1 on Python 3.12 with apache-airflow-providers-microsoft-azure==15.0.0rc1 installed from PyPI into a clean venv, compared against 14.1.0 (the previous stable) in a second venv.

   Functional check. Built an MSGraphAsyncOperator carrying a full request configuration (headers, data, scopes), fed it a first page ending in @odata.nextLink, and inspected the MSGraphTrigger the operator defers to for page 2:

   field	14.1.0	15.0.0rc1
   headers	None ❌	{'Prefer': 'outlook.timezone="Europe/Brussels"', 'ConsistencyLevel': 'eventual'} ✅
   data	None ❌	{'filter': "displayName eq 'x'"} ✅
   scopes	None ❌	['https://graph.microsoft.com/.default'] ✅
   method	GET ✅	GET ✅
   conn_id	msgraph_api ✅	msgraph_api ✅

   So on 14.1.0 the second and later pages were issued without the caller's headers, body, and scopes, which is what the fix addresses. On the RC all five survive the pagination hand-off.

   Test suite. Ran the provider's MSGraph unit tests (operators, triggers, hooks) from main against the installed RC wheel: 92 passed, 1 xfailed.

   Also diffed the shipped 15.0.0rc1 wheel against main, operators/msgraph.py matches, so the release artifact carries the merged change.

   Addressed ✅
7. jason810496 commented on Aug 20, 2026

   

   jason810496

   on Aug 20, 2026

   Last edited by jason810496

   Member

   More actions

   I verified apache-airflow-providers-standard==1.18.0rc1, including the is_stub=True change from #69757. Everything works as expected, and I've checked the corresponding box above as well.
8. AlejandroMorgante commented on Aug 20, 2026

   

   AlejandroMorgante

   on Aug 20, 2026

   Last edited by AlejandroMorgante

   Contributor

   More actions

   Validated my change included in the current provider RC round:

   • apache-airflow-providers-google==22.4.0rc1 — Add synchronous Vertex AI Agent Engine query operator #70933: example_vertex_ai_agent_engine.py passed against real GCP (1 passed in 1046.82s). The test exercised Agent Engine creation and retrieval, the new synchronous query with RunReasoningEngineQueryOperator, synchronous and deferrable query jobs, update, and delete flows. The published RC wheel was installed from PyPI with provider sources unmounted. Post-test checks confirmed that the temporary GCS bucket, Artifact Registry repository, and Reasoning Engine were all removed.

   Environment: Breeze, Airflow 3.3.1, Python 3.10
9. Beat-Nick commented on Aug 20, 2026

   

   Beat-Nick

   on Aug 20, 2026

   Contributor

   More actions

   I verified databricks: 7.19.0rc1 native retry changes from PR #69182 against Databricks: standalone + workflow, sync + deferrable, precedence, templating, retry_on_timeout via real TIMEDOUT attempts
10. haseebmalik18 commented on Aug 20, 2026

    

    haseebmalik18

    on Aug 20, 2026

    Last edited by haseebmalik18

    Contributor

    More actions

    Verified my three items: samba 4.13.0rc1 (#64643), microsoft.azure 15.0.0rc1 (#70879) and amazon 9.35.0rc1 (#70152). Installed each RC from PyPI on Airflow 3.3.1 and confirmed all three fixes work as expected.
11. 1fanwang commented on Aug 20, 2026

    

    1fanwang

    on Aug 20, 2026

    Last edited by 1fanwang

    Contributor

    More actions

    Tested apache-airflow-providers-apache-iceberg==2.1.0rc1 from PyPI for #71387 on Airflow 3.3.1 and Python 3.12.

    A real airflow standalone stack watched default.orders in a persistent PyIceberg SQL catalog. The first snapshot created one successful asset-triggered Dag run. Restarting the stack did not create a duplicate. A second snapshot created one more successful run, and the stored watermark moved to the new snapshot.

    Raw evidence

    airflow=3.3.1
    provider=2.1.0rc1
    trigger_file=/usr/python/lib/python3.12/site-packages/airflow/providers/apache/iceberg/triggers/iceberg.py
    
    init_snapshot_id=7521888404468231469
    standalone_run_1=ready
    dag_runs=[('asset_triggered__2026-08-20T20:28:40.550574+00:00_FIP5pzbK', 'asset_triggered', 'success')]
    watchers=[('airflow.providers.apache.iceberg.triggers.iceberg.IcebergTableSnapshotTrigger', 'orders_commits', 'iceberg_orders')]
    watermarks=[('iceberg_orders', 'snapshot_id', '7521888404468231469', 'watcher')]
    
    standalone_run_2=ready
    dag_runs=[('asset_triggered__2026-08-20T20:28:40.550574+00:00_FIP5pzbK', 'asset_triggered', 'success')]
    watermarks=[('iceberg_orders', 'snapshot_id', '7521888404468231469', 'watcher')]
    
    append_snapshot_id=511192996627067273
    dag_runs=[('asset_triggered__2026-08-20T20:28:40.550574+00:00_FIP5pzbK', 'asset_triggered', 'success'), ('asset_triggered__2026-08-20T20:30:14.639421+00:00_eqMjmKHK', 'asset_triggered', 'success')]
    watermarks=[('iceberg_orders', 'snapshot_id', '511192996627067273', 'watcher')]
    RC_E2E_RESULT=PASS

    Addressed.

    ---

    Drafted-by: GitHub Copilot CLI (GPT-5.6 Sol) (human reviewed before posting)
12. 1fanwang commented on Aug 20, 2026

    

    1fanwang

    on Aug 20, 2026

    Last edited by 1fanwang

    Contributor

    More actions

    Tested apache-airflow-providers-microsoft-psrp==3.2.7rc1 from PyPI for #70347 on Airflow 3.3.1 and Python 3.12.

    I parsed the same Dags against 3.2.6 and the RC. Stable rejected provided-but-empty options and accepted equal values for command and powershell. The RC loaded the empty options, rejected the duplicate options, and kept a command that rendered to "" on the command dispatch path.

    The Dag parse used Airflow's real DagBag. I isolated the transport for the dispatch check because no Windows WinRM endpoint was available.

    Raw evidence

    == PSRP 3.2.6 baseline ==
    provider=3.2.6
    operator_file=/usr/python/lib/python3.12/site-packages/airflow/providers/microsoft/psrp/operators/psrp.py
    valid_empty_options_loaded=False errors=["ValueError: Must provide exactly one of 'command', 'powershell', or 'cmdlet'"]
    equal_options_rejected=False errors=[]
    rendered_empty_command_dispatched=None
    
    == PSRP 3.2.7rc1 ==
    provider=3.2.7rc1
    operator_file=/usr/python/lib/python3.12/site-packages/airflow/providers/microsoft/psrp/operators/psrp.py
    valid_empty_options_loaded=True errors=[]
    equal_options_rejected=True errors=["ValueError: Must provide exactly one of 'command', 'powershell', or 'cmdlet'"]
    rendered_empty_command_dispatched=True

    Addressed.

    ---

    Drafted-by: GitHub Copilot CLI (GPT-5.6 Sol) (human reviewed before posting)
13. VladaZakharova commented on Aug 21, 2026

    

    VladaZakharova

    on Aug 21, 2026

    Contributor

    More actions

    Tested and verified for Google provider, everything looks good, +2
14. dhkim1920 commented on Aug 22, 2026

    

    dhkim1920

    on Aug 22, 2026

    Contributor

    More actions

    Validated my change included in the current provider RC round:

    • apache-airflow-providers-keycloak==0.9.0rc2 — Fix Keycloak access for individual roles #70906

    I reviewed the relevant implementation and verified that the RC creates the team ReadOnly permission with the AFFIRMATIVE strategy while retaining the individual Viewer, User, Op, and Admin policies.

    I also tested the behavior before and after the change by restoring the team ReadOnly permission to its previous UNANIMOUS strategy in the same provisioned realm:

    Team ReadOnly strategy	Client resource-server strategy	Viewer UMA result
    Previous: UNANIMOUS	AFFIRMATIVE	HTTP 403
    Current RC: AFFIRMATIVE	AFFIRMATIVE	HTTP 200 with Dag:team-a / GET granted

    This confirms that #70906 changes the Viewer result from denied to granted as intended.

    One configuration requirement should be documented: the Keycloak client's resource-server-level decision strategy must also be AFFIRMATIVE. With Keycloak's default UNANIMOUS client strategy, the Viewer request returned HTTP 403 both before and after the permission-level change. The provider documentation and provisioning CLI do not currently document or validate this requirement.

    Environment: Breeze with mounted provider sources removed, Airflow 3.3.1, Python 3.10, Keycloak 23.0.6, PostgreSQL 14.

    ---

    Drafted-by: OpenAI Codex (GPT-5); reviewed by @dhkim1920 before posting
15. Vamsi-klu commented on Aug 22, 2026

    

    Vamsi-klu

    on Aug 22, 2026 · Hidden as spam

    show commentMore actions
16. baha-bouali commented on Aug 23, 2026

    

    baha-bouali

    on Aug 23, 2026

    Contributor

    More actions

    apache.hdfs 4.13.0rc1 ::: #71278 ✅

    • HdfsRemoteLogIO.from_config() with remote_base_log_folder = hdfs://namenode:8020/airflow/logs returns remote_base = '/airflow/logs'
      The urlsplit(...). path stripping matches the legacy airflow_local_settings.py branch, and base_log_folder is expanded correctly.

    • The hdfs scheme is registered in the shipped provider metadata, mapped to airflow.providers.apache.hdfs.log.hdfs_task_handler.HdfsRemoteLogIO.

    • Note: on 3.1.3 the ProvidersManager-based dispatch from Decouple remote logging config from core #67056 isn't present yet. The hardcoded startswith("hdfs://") branch is still what runs. So the registration is correct but dormant on this version; it would need re-testing on the Airflow release that carries the core-side consumer.
17. baha-bouali commented on Aug 23, 2026

    

    baha-bouali

    on Aug 23, 2026

    Contributor

    More actions

    microsoft.azure 15.0.0rc1::: #71071 ⚠️ partial

    • Installs cleanly, provider loads, AzureBatchHook imports without error.
    • Could not verify live authentication. In fact, my Azure for Students subscription blocks Batch account creation by region policy. The get_conn() credential path is untested; would appreciate someone with a live Batch account confirming.
18. ColtenOuO commented on Aug 23, 2026

    

    ColtenOuO

    on Aug 23, 2026

    Contributor

    More actions

    Thanks for preparing the release!

    Verified #71738 and #71445 in the common-ai provider, work as expected.
19. hussein-awala commented on Aug 23, 2026

    

    hussein-awala

    on Aug 23, 2026

    Last edited by hussein-awala

    MemberAuthor

    More actions

    Thank you everyone. Providers are released.

    28 providers from this wave are now on PyPI and their documentation is live at https://airflow.apache.org/docs/

    apache-airflow-providers-fab was excluded from the release. 3.8.1rc1 broke Azure AD SSO for deployments configuring the tenant authority with a domain name or an uppercase tenant GUID, reported by Aaron Chen during the vote. A fix is in review in #71920, and fab will be re-cut as 3.8.1rc2 either ad-hoc or in the next wave. The fab items ticked above stay ticked and will carry over, so nobody needs to re-verify them.

    Thanks in particular to everyone who ran real deployments against the RCs rather than just installing them — the Keycloak JWT cookie testing on 3.3.0, the MSGraph pagination comparison against 14.1.0, the Iceberg snapshot watermark end-to-end run, the Vertex AI Agent Engine run against live GCP, and the PSRP baseline diff were all genuinely useful. And thanks to Aaron for the -1: it caught a regression that would otherwise have shipped.

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

    closed this as completedon Aug 23, 2026