Status of testing Providers that were prepared on August 01, 2026 #70953

Activity

1. potiuk

   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 3, 2026
2. AlejandroMorgante commented on Aug 3, 2026

   

   AlejandroMorgante

   on Aug 3, 2026

   Last edited by AlejandroMorgante

   Contributor

   More actions

   Validated my change included in the current provider RC round:

   • apache-airflow-providers-amazon==9.34.0rc1 — Add DmsReloadTablesOperator #70569: example_dms.py passed against real AWS (1 passed in 2707.18s). The test exercised a full-load-and-CDC replication task plus deferrable data-reload and validate-only operations with DmsReloadTablesOperator. The table reached Table completed and Validated, with zero full-load errors and zero validation failures. Post-test checks confirmed that all temporary RDS and DMS resources were removed.

   Environment: Breeze, Python 3.10

   🚀React with 🚀1Reacted by Jarek Potiuk
3. MannXo commented on Aug 3, 2026

   

   MannXo

   on Aug 3, 2026

   Contributor

   More actions

   Tested my three changes in this RC round. All three behave as intended.

   Setup: apache-airflow==3.3.0 in a clean venv on Python 3.12, one provider RC installed per check, real backends in Docker (MongoDB 7, MinIO for S3, Weaviate 1.28.4). Each case is a real DAG run via airflow dags test, with render_template_as_native_obj=True and the templated field pulled from an upstream XCom, since all three fixes are about when a template field is inspected.

   For each one I also ran the same DAG against the previous release to confirm the RC actually changes the behaviour.

   ---

   apache-airflow-providers-amazon==9.34.0rc1, #70330 (MongoToS3Operator)

   mongo_query rendering to a list now takes the aggregate path:

   CASE 1: mongo_query renders to a list -> aggregate pipeline
   s3://rc-bucket/pipeline.json -> {"_id": "red", "total": 7}
   CASE 2: mongo_query renders to a dict -> find
   s3://rc-bucket/find.json -> {"_id": 1, ...} | {"_id": 2, ...}
   

   The $group result can only come from aggregate, so that pins the path. On 9.33.0 the same DAG fails, because is_pipeline was decided in __init__ from the un-rendered string and the rendered list went to find:

   TypeError: filter must be an instance of dict, bson.son.SON, or any other type
   that inherits from collections.Mapping
   

   apache-airflow-providers-cohere==1.6.7rc1, #70325 (CohereEmbeddingOperator)

   I have no Cohere API key, so the connection's base_url points at a local stub of the /v2/embed endpoint. The operator and the Cohere SDK are real, only the remote is not, which is enough to see the exact payload that goes out:

   CASE 1: input_text renders to a single string
     -> POST /v2/embed  texts=["a single sentence"]
   CASE 2: input_text renders to a list of strings
     -> POST /v2/embed  texts=["first sentence", "second sentence"]
   

   On 1.6.6 case 2 sends a nested list, since __init__ wrapped the un-rendered "{{ ... }}" string and templating then filled the list element in:

   texts=[["first sentence", "second sentence"]]
   

   apache-airflow-providers-weaviate==3.4.1rc1, #70326 (WeaviateIngestOperator)

   CASE 1: input_data templated from XCom, renders to a list of objects
     objects in weaviate: ['alpha', 'beta']
   CASE 2: the same field renders to None
     TypeError: input_data is required   (task failed, nothing ingested)
   

   On 3.4.0 case 2 gets TypeError: 'NoneType' object is not iterable from inside WeaviateHook.batch_data instead. Same failure, clearer message, and constructing the operator with input_data=None no longer raises at DAG parse time.

   ---

   No other issues seen with these three distributions.

   🎉React with 🎉1Reacted by Jarek Potiuk
4. Andrushika commented on Aug 3, 2026

   

   Andrushika

   on Aug 3, 2026

   Contributor

   More actions

   Thanks for preparing the release, Jarek!

   A side note: Some mentions in the issue body did not take effect. The body mentions many different users, but in the rendered body only the first 50 are real mention links. I did not get the notification from GitHub, but found this RC testing through the vote email instead. I think a follow-up comment that mentions the remaining users may reach them.

   Tested #70301 with apache-airflow-providers-microsoft-azure==14.1.0rc1 on released Airflow 3.3.0. Setup: breeze --use-airflow-version 3.3.0, RC wheel from PyPI, Azurite as the blob backend.

   • ProvidersManager().remote_logging_handler_by_scheme("wasb") returns WasbRemoteLogIO. The scheme is registered on the released core.
   • resolve_remote_task_log with remote_base_log_folder = wasb://rc-test/logs builds WasbRemoteLogIO through provider dispatch. I mocked the legacy discovery and it was not called.
   • WasbRemoteLogIO.from_config() reads the [logging] section as expected. The wasb:// prefix is stripped and the container falls back to airflow-logs.
   • Uploaded a log file with io.upload() and read it back with io.read() against Azurite. The content matched and the log source URL points at the right blob.

   Works as expected.

   Drafted-by: Claude Code (Fable 5); reviewed by @Andrushika before posting

   ❤️React with ❤️1Reacted by Jarek Potiuk
5. raphaelauv commented on Aug 3, 2026

   

   raphaelauv

   on Aug 3, 2026

   Contributor

   More actions

   #70480

   works , thanks

   👍React with 👍1Reacted by Jarek Potiuk
6. aaron-y-chen commented on Aug 3, 2026

   

   aaron-y-chen

   on Aug 3, 2026

   Contributor

   More actions

   #69893 and #70504 work well on my local machine :)

   🚀React with 🚀1Reacted by Jarek Potiuk
7. stephen-bracken commented on Aug 3, 2026

   

   stephen-bracken

   on Aug 3, 2026

   Contributor

   More actions

   Regarding #70550 - Since it relies on the new middleware from #70800 I am going to limit this change to Airflow v3.30+ to avoid issues with backwards compatibility, see #70981

   👍React with 👍1Reacted by Jarek Potiuk
8. stephen-bracken commented on Aug 3, 2026

   

   stephen-bracken

   on Aug 3, 2026

   Contributor

   More actions

   tested #70800 on 3.3.0, it looks like the middleware isn't setting the Airflow JWT correctly and the login is redirect looping, so we'll have to hold this change for now

   👍React with 👍1Reacted by Jarek Potiuk
9. justinpakzad commented on Aug 3, 2026

   

   justinpakzad

   on Aug 3, 2026

   Contributor

   More actions

   Confirming #70478 has been tested and working as expected. #70332 and #70874 were also tested and raise appropriately.

   🎉React with 🎉1Reacted by Jarek Potiuk
10. onlyarnav commented on Aug 4, 2026

    

    onlyarnav

    on Aug 4, 2026

    Member

    More actions

    Verified that the #68679 backend strategy refactor preserves all existing behavior and public API contracts across Standalone, YARN, and K8s modes.
    I'll open a quick follow-up PR to fix the missing space in the _YarnSparkSubmitBackend exception message ("conflicts with") and look into promoting those private hook properties to public methods.

    ❤️React with ❤️1Reacted by Jarek Potiuk
11. potiuk commented on Aug 4, 2026

    

    potiuk

    on Aug 4, 2026

    MemberAuthor

    More actions

    Thanks everyone for the testing — the status issue is updated, 15 more boxes ticked.

    Confirmed working and checked off:

    PR	Provider	Verified by
    #69786	airbyte 6.0.1rc1	Steve Ahn (dev@)
    #69676 / #70569 / #70330	amazon 9.34.0rc1	Steve Ahn (dev@) / @AlejandroMorgante / @MannXo
    #68679	apache.spark 6.3.1rc1	@onlyarnav
    #70325	cohere 1.6.7rc1	@MannXo
    #69736 / #69893	common.sql 2.1.0rc1	Steve Ahn (dev@) / @aaron-y-chen
    #70478	fab 3.8.0rc1	@justinpakzad
    #70504	google 22.3.0rc2	@aaron-y-chen
    #70301	microsoft.azure 14.1.0rc1	@Andrushika, Andrew Chang (dev@)
    #70332 / #70874	snowflake 6.16.0rc1	@justinpakzad
    #70480	standard 1.17.0rc1	@raphaelauv
    #70326	weaviate 3.4.1rc1	@MannXo

    Special thanks for the depth of several of these — real AWS DMS full-load-and-CDC runs, before/after comparisons against the previous release that pin the actual behaviour change, and a real Azurite round-trip rather than a mock.

    The following six providers are being removed from the 2026-08-01 wave and will be re-cut once the fixes land:

    • keycloak 0.9.0rc1 — Add KeycloakJWTMiddleware to KeycloakAuthManager #70800 (KeycloakJWTMiddleware) does not set the Airflow JWT correctly on 3.3.0 and the login redirect-loops; Move keycloak JWT tokens to separate cookies #70550 sits on top of it and additionally needs limiting to 3.3.0+ (Disable separate Keycloak JWTs for Airflow v3.2- #70981).
    • clickhousedb 1.0.1rc2 — the release carries only the lifecycle metadata change (Change Clickhouse lifecycle to incubation #69166), which does not warrant a release of its own.
    • amazon 9.34.0rc1, microsoft.azure 14.1.0rc1, google 22.3.0rc2, yandex 4.5.1rc1 — the secrets-backend team-scoping work (Refuse the team agnostic fall-through for a team scoped AWS secret name #70878, Refuse the team agnostic fall-through for a team scoped Key Vault secret name #70876, Apply the ambiguous-id refusal to get_config in the Key Vault backend #70899, Apply the team scope in the Google Secret Manager backend #70869, Refuse the team agnostic fall-through for a team scoped Lockbox secret name #70877, Only resolve a team namespaced environment secret for its own team #70736) refuses to resolve any connection / variable / config id containing the team-namespace separator, unconditionally — including in deployments that never enabled multi-team. An ordinary id containing -- (or __ on Azure, which normalises _ to - before the check) is silently treated as missing, with only a log.warning. Fix is in Only refuse team scoped like secret ids when multi_team is on #71078.

    The checkmarks already earned on those six stay ticked and carry over to the re-cut, so testers do not need to repeat that work.

    Still open, not a removal: there is a temporary -1 on dev@ against anything carrying #70791 (limiting pandas to <3 for DataFrame XComs) pending a catch-up on the reasoning. That touches 14 providers in this wave (amazon, apache.hdfs, apache.hive, common.sql, databricks, exasol, google, papermill, postgres, presto, salesforce, snowflake, trino, weaviate) and also affects Airflow core, so it is being resolved on the dev list rather than by pulling providers.

    One housekeeping note raised in this thread: GitHub only renders the first 50 @-mentions in an issue body, so contributors past that cut-off were never notified and found the RC through the vote email instead. Worth a follow-up comment mentioning the rest.

    ---

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

    ❤️React with ❤️1Reacted by Alejandro Morgante
12. stephen-bracken commented on Aug 4, 2026

    

    stephen-bracken

    on Aug 4, 2026

    Contributor

    More actions

    fix for #70800 added in #71077

    👍React with 👍1Reacted by Jarek Potiuk
13. baha-bouali commented on Aug 4, 2026

    

    baha-bouali

    on Aug 4, 2026

    Contributor

    More actions

    Tested apache-airflow-providers-alibaba==3.4.0rc1 against Airflow core 3.3.0. Works as expected 👍

    🚀React with 🚀1Reacted by Jarek Potiuk
14. 1fanwang commented on Aug 5, 2026

    

    1fanwang

    on Aug 5, 2026

    Contributor

    More actions

    Verified Strip GlueDataQualityOperator ruleset after rendering on amazon 9.34.0rc1. Works as intended.

    Airflow 3.3.0, two identical virtualenvs: one with the RC providers, one with the previous stable release. Same Dag, same command, run through the real task runner. The external transport is stubbed, and the stub asserts the value that actually reaches it.

    A GlueDataQualityOperator whose rule_set comes from a param, so the leading and trailing whitespace only exists after rendering. The stubbed boto3 client asserts the ruleset string it is handed.

    # amazon 9.34.0rc1
    AIRFLOW_HOME=$PWD/airflow_home \
    AIRFLOW__CORE__DAGS_FOLDER=$PWD/dags_e2e/rc_70331_glue_ruleset \
      .venv/bin/airflow dags test rc_70331_glue_ruleset
    
    # amazon 9.33.0, identical Dag
    AIRFLOW_HOME=$PWD/airflow_home_prev \
    AIRFLOW__CORE__DAGS_FOLDER=$PWD/dags_e2e/rc_70331_glue_ruleset \
      .venv-prev/bin/airflow dags test rc_70331_glue_ruleset

    # amazon 9.34.0rc1
    RC_CHECK_OK ruleset sent to AWS = 'Rules = [ ColumnLength "review_id" = 9 ]'
    state=success
    
    # amazon 9.33.0
    AttributeError: RuleSet must starts with Rules = [ and ends with ]
    state=failed
    

    🎉React with 🎉1Reacted by Jarek Potiuk
15. 8 remaining items

    Load more

16. 1fanwang commented on Aug 5, 2026

    

    1fanwang

    on Aug 5, 2026

    Contributor

    More actions

    Verified Validate DatabricksSQLStatementsSensor statement fields after rendering on databricks 7.18.1rc1. Works as intended.

    Airflow 3.3.0, two identical virtualenvs: one with the RC providers, one with the previous stable release. Same Dag, same command, run through the real task runner. RPC is stubbed, and the stub asserts the value that actually reaches it.

    A DatabricksSQLStatementsSensor with statement="SELECT 1" and a templated statement_id that renders to empty, so only one of the two is set after rendering.

    # databricks 7.18.1rc1
    AIRFLOW_HOME=$PWD/airflow_home \
    AIRFLOW__CORE__DAGS_FOLDER=$PWD/dags_e2e/rc_70340_databricks_sql_sensor \
      .venv/bin/airflow dags test rc_70340_databricks_sql_sensor
    
    # databricks 7.18.0, identical Dag
    AIRFLOW_HOME=$PWD/airflow_home_prev \
    AIRFLOW__CORE__DAGS_FOLDER=$PWD/dags_e2e/rc_70340_databricks_sql_sensor \
      .venv-prev/bin/airflow dags test rc_70340_databricks_sql_sensor

    # databricks 7.18.1rc1
    RC_CHECK_OK statement submitted: 'SELECT 1'
    state=success
    
    # databricks 7.18.0, no task ever runs
    Error loading DAG from rc_70340_databricks_sql_sensor.py:
    AirflowException: Cannot provide both statement and statement_id.
    

    🚀React with 🚀1Reacted by Jarek Potiuk
17. 1fanwang commented on Aug 5, 2026

    

    1fanwang

    on Aug 5, 2026

    Contributor

    More actions

    Verified Validate DatabricksCopyIntoOperator template fields after rendering on databricks 7.18.1rc1. Works as intended.

    Airflow 3.3.0, two identical virtualenvs: one with the RC providers, one with the previous stable release. Same Dag, same command, run through the real task runner. RPC is stubbed, and the stub asserts the value that actually reaches it.

    A DatabricksCopyIntoOperator with pattern="*.json" and a templated files that renders to empty, which is the "use the pattern unless an explicit file list is passed" case. The stub prints the SQL that reaches the warehouse.

    # databricks 7.18.1rc1
    AIRFLOW_HOME=$PWD/airflow_home \
    AIRFLOW__CORE__DAGS_FOLDER=$PWD/dags_e2e/rc_70339_databricks_copy_into \
      .venv/bin/airflow dags test rc_70339_databricks_copy_into
    
    # databricks 7.18.0, identical Dag
    AIRFLOW_HOME=$PWD/airflow_home_prev \
    AIRFLOW__CORE__DAGS_FOLDER=$PWD/dags_e2e/rc_70339_databricks_copy_into \
      .venv-prev/bin/airflow dags test rc_70339_databricks_copy_into

    # databricks 7.18.1rc1
    RC_CHECK_OK sql reached the warehouse:
    COPY INTO my_catalog.my_schema.my_table
    FROM 's3://bucket/data'
    FILEFORMAT = JSON
    PATTERN = '*.json'
    state=success
    
    # databricks 7.18.0, no task ever runs
    Error loading DAG from rc_70339_databricks_copy_into.py:
    AirflowException: Only one of 'pattern' or 'files' should be specified
    

    🎉React with 🎉1Reacted by Jarek Potiuk
18. 1fanwang commented on Aug 5, 2026

    

    1fanwang

    on Aug 5, 2026

    Contributor

    More actions

    Verified Derive DbtCloudGetJobRunArtifactOperator default file name after rendering on dbt-cloud 4.9.3rc1. Works as intended.

    Airflow 3.3.0, two identical virtualenvs: one with the RC providers, one with the previous stable release. Same Dag, same command, run through the real task runner. RPC is stubbed, and the stub asserts the value that actually reaches it.

    A DbtCloudGetJobRunArtifactOperator with a templated artifact path and no explicit output_file_name, so the default name is derived from the rendered path.

    # dbt-cloud 4.9.3rc1
    AIRFLOW_HOME=$PWD/airflow_home \
    AIRFLOW__CORE__DAGS_FOLDER=$PWD/dags_e2e/rc_70336_dbt_artifact \
      .venv/bin/airflow dags test rc_70336_dbt_artifact
    
    # dbt-cloud 4.9.2, identical Dag
    AIRFLOW_HOME=$PWD/airflow_home_prev \
    AIRFLOW__CORE__DAGS_FOLDER=$PWD/dags_e2e/rc_70336_dbt_artifact \
      .venv-prev/bin/airflow dags test rc_70336_dbt_artifact

    # dbt-cloud 4.9.3rc1
    [info] Writing path/to/manifest.json artifact for job run 1234 to 1234_path-to-manifest.json
    RC_CHECK_OK artifact name flattened from the RENDERED path
    state=success
    
    # dbt-cloud 4.9.2
    AssertionError: expected '1234_path-to-manifest.json', got '1234_path/to/manifest.json'
    state=failed
    

    The previous release derived the name from the un-rendered template, so the slashes survived into the file name.

    ❤️React with ❤️1Reacted by Jarek Potiuk
19. 1fanwang commented on Aug 5, 2026

    

    1fanwang

    on Aug 5, 2026

    Contributor

    More actions

    Verified Handle DockerOperator mounts after rendering on docker 4.5.9rc1. Works as intended.

    Airflow 3.3.0, two identical virtualenvs: one with the RC providers, one with the previous stable release. Same Dag, same command, run through the real task runner. Only the external transport is stubbed, and the stub asserts the value that actually reaches it.

    A DockerOperator with a mount whose source comes from a param. No docker daemon on this machine, so the API client is stubbed and asserts the mount handed to create_host_config.

    # docker 4.5.9rc1
    AIRFLOW_HOME=$PWD/airflow_home \
    AIRFLOW__CORE__DAGS_FOLDER=$PWD/dags_e2e/rc_70342_docker_mounts \
      .venv/bin/airflow dags test rc_70342_docker_mounts
    
    # docker 4.5.8, identical Dag
    AIRFLOW_HOME=$PWD/airflow_home_prev \
    AIRFLOW__CORE__DAGS_FOLDER=$PWD/dags_e2e/rc_70342_docker_mounts \
      .venv-prev/bin/airflow dags test rc_70342_docker_mounts

    # docker 4.5.9rc1
    MOUNTS_TO_DOCKER_PY=[{'Target': '/data', 'Source': '/tmp/rc-data', 'Type': 'bind', 'ReadOnly': False}]
    state=success
    
    # docker 4.5.8
    MOUNTS_TO_DOCKER_PY=[{'Target': '/data', 'Source': '/tmp/rc-data', 'Type': 'bind', 'ReadOnly': False}]
    state=success
    

    Identical on both, so this is a no-regression result.

    🚀React with 🚀1Reacted by Jarek Potiuk
20. 1fanwang commented on Aug 5, 2026

    

    1fanwang

    on Aug 5, 2026

    Contributor

    More actions

    Verified Validate AzureVirtualMachineStateSensor target_state after rendering on microsoft-azure 14.1.0rc1. Works as intended.

    Airflow 3.3.0, two identical virtualenvs: one with the RC providers, one with the previous stable release. Same Dag, same command, run through the real task runner. RPC is stubbed, and the stub asserts the value that actually reaches it.

    An AzureVirtualMachineStateSensor with a templated target_state.

    # microsoft-azure 14.1.0rc1
    AIRFLOW_HOME=$PWD/airflow_home \
    AIRFLOW__CORE__DAGS_FOLDER=$PWD/dags_e2e/rc_70329_azure_vm_state \
      .venv/bin/airflow dags test rc_70329_azure_vm_state
    
    # microsoft-azure 14.0.0, identical Dag
    AIRFLOW_HOME=$PWD/airflow_home_prev \
    AIRFLOW__CORE__DAGS_FOLDER=$PWD/dags_e2e/rc_70329_azure_vm_state \
      .venv-prev/bin/airflow dags test rc_70329_azure_vm_state

    # microsoft-azure 14.1.0rc1
    RC_CHECK_OK azure polled rg='rg-prod' vm='vm-1'
    state=success
    
    # microsoft-azure 14.0.0, no task ever runs
    Error loading DAG from rc_70329_azure_vm_state.py:
    ValueError: Invalid target_state: {{ params.state }}. Must be one of ['deallocated', 'deallocating', 'running', 'starting', 'stopped']
    

    🎉React with 🎉1Reacted by Jarek Potiuk
21. 1fanwang commented on Aug 5, 2026

    

    1fanwang

    on Aug 5, 2026

    Contributor

    More actions

    Verified Fix DateTimeSensor crash when target_time renders to a datetime on standard 1.17.0rc1. Works as intended.

    Airflow 3.3.0, two identical virtualenvs: one with the RC providers, one with the previous stable release. Same Dag, same command, run through the real task runner. RPC is stubbed, and the stub asserts the value that actually reaches it.

    A DateTimeSensor whose target_time renders to a native datetime rather than a string.

    # standard 1.17.0rc1
    AIRFLOW_HOME=$PWD/airflow_home \
    AIRFLOW__CORE__DAGS_FOLDER=$PWD/dags_e2e/rc_70320_datetime_sensor \
      .venv/bin/airflow dags test rc_70320_datetime_sensor
    
    # standard 1.16.0, identical Dag
    AIRFLOW_HOME=$PWD/airflow_home_prev \
    AIRFLOW__CORE__DAGS_FOLDER=$PWD/dags_e2e/rc_70320_datetime_sensor \
      .venv-prev/bin/airflow dags test rc_70320_datetime_sensor

    # standard 1.17.0rc1
    RC_CHECK_OK DateTimeSensor poked with a native datetime and passed
    state=success
    
    # standard 1.16.0
    TypeError: argument 'input': 'DateTime' object cannot be cast as 'str'
    state=failed
    

    ❤️React with ❤️1Reacted by Jarek Potiuk
22. ColtenOuO commented on Aug 5, 2026

    

    ColtenOuO

    on Aug 5, 2026

    Last edited by ColtenOuO

    Contributor

    More actions

    Thanks for preparing the release!

    Verified #70474 and #70431. (Works as expected)

    🎉React with 🎉1Reacted by Jarek Potiuk
23. 1fanwang commented on Aug 5, 2026

    

    1fanwang

    on Aug 5, 2026

    Last edited by 1fanwang

    Contributor

    More actions

    Verified Read HITLOperator subject/body into the summary lazily on standard 1.17.0rc1. Works as intended.

    Airflow 3.3.0, two identical virtualenvs: one with the RC providers, one with the previous stable release. Same Dag, same command, run through the real task runner. RPC is stubbed, and the stub asserts the value that actually reaches it.

    An ApprovalOperator with templated subject and body, plus a listener reading ti.task.hitl_summary in on_task_instance_running. Nothing about the operator is stubbed. The task parks in AWAITING_INPUT, a response is recorded through the same path the HITL REST API uses, and the task resumes.

    # standard 1.17.0rc1, responder drives the human side of the same run
    AIRFLOW_HOME=$PWD/airflow_home \
    AIRFLOW__CORE__DAGS_FOLDER=$PWD/dags_e2e/rc_70345_hitl_summary \
      .venv/bin/airflow dags test rc_70345_hitl_summary &
    AIRFLOW_HOME=$PWD/airflow_home \
      .venv/bin/python hitl_responder.py rc_70345_hitl_summary approve_deploy Approve
    
    # standard 1.16.0, same Dag, same responder
    AIRFLOW_HOME=$PWD/airflow_home_prev \
    AIRFLOW__CORE__DAGS_FOLDER=$PWD/dags_e2e/rc_70345_hitl_summary \
      .venv-prev/bin/airflow dags test rc_70345_hitl_summary &
    AIRFLOW_HOME=$PWD/airflow_home_prev \
      .venv-prev/bin/python hitl_responder.py rc_70345_hitl_summary approve_deploy Approve

    # standard 1.17.0rc1, Dag run: what the listener was handed
    LISTENER_SAW_SUMMARY subject='Approve deploy to prod?' body='Release 2026.8.1 is ready for prod.'
    RC_CHECK_OK listener saw the RENDERED subject/body
    [info] Pausing task as AWAITING_INPUT. [task] dag_id=rc_70345_hitl_summary task_id=approve_deploy loc=task_runner.py:1491
    [info] Task instance state updated ... new_state=success
    DagRun Finished: dag_id=rc_70345_hitl_summary ... state=success
    
    # standard 1.17.0rc1, responder acting as the human on that same run
    HITL_REQUEST_SEEN_BY_HUMAN subject='Approve deploy to prod?' body='Release 2026.8.1 is ready for prod.'
    HUMAN_RESPONDS chosen_options=['Approve']
    RESPONSE_RECORDED task resumed
    
    # standard 1.16.0, same Dag, same responder
    LISTENER_SAW_SUMMARY subject='Approve deploy to {{ params.env }}?' body='Release {{ params.release }} is ready for {{ params.env }}.'
    AssertionError: subject is un-rendered Jinja: 'Approve deploy to {{ params.env }}?'
    [error] error calling listener        (x2)
    

    One non-back-compat note: hitl_summary is now a property with no setter, so a subclass that extended it in __init__ on 1.16.0 now has its entry silently dropped rather than raising.
24. 1fanwang commented on Aug 5, 2026

    

    1fanwang

    on Aug 5, 2026

    Last edited by 1fanwang

    Contributor

    More actions

    Verified Opt-in concurrent pod creation in KubernetesExecutor on cncf-kubernetes 10.21.0rc1.

    Minor issue - The behavior is correct, but the RC ships a wrong versionadded on both new config options, which is my mistake. Details at the bottom. I do not think it blocks the release, see #71157.

    Airflow 3.3.0, two identical virtualenvs: one with the RC providers, one with the previous stable release.

    This is scheduler-loop code, so it is not a Dag run. Instead the real KubernetesExecutor.sync() is driven with 12 jobs on its real task queue, with the Kubernetes API stubbed at a fixed 0.25s per create call so the concurrency is measurable.

    # cncf-kubernetes 10.21.0rc1, flag on and off
    .venv/bin/python k8s_executor_e2e.py true
    .venv/bin/python k8s_executor_e2e.py false
    
    # cncf-kubernetes 10.20.0
    .venv-prev/bin/python k8s_executor_e2e.py true

    # cncf-kubernetes 10.21.0rc1, async_pod_creation=True
    async_pod_creation=True
    pod_creation_max_concurrency=12
    QUEUED_PODS=12 latency_per_create=0.25s
    PODS_CREATED=12
    WALL_CLOCK=0.26s
    FIRST_TO_LAST_CREATE_START=0.00s
    SEQUENTIAL_WOULD_COST=3.00s
    
    # cncf-kubernetes 10.21.0rc1, async_pod_creation=False (the default)
    async_pod_creation=False
    PODS_CREATED=12
    WALL_CLOCK=3.09s
    FIRST_TO_LAST_CREATE_START=2.84s
    
    # cncf-kubernetes 10.20.0, the code path does not exist
    AttributeError: <class '...AirflowKubernetesScheduler'> does not have the attribute '_build_pod_request'
    

    Wrong versionadded on both new options

    PR moving both to 10.21.0: #71157

    👀React with 👀1Reacted by Jarek Potiuk
25. SameerMesiah97 commented on Aug 5, 2026

    

    SameerMesiah97

    on Aug 5, 2026

    Contributor

    More actions

    apache-airflow-providers-common-sql==2.1.0rc1

    PR #69362: Changes are working as expected with no observed regressions.

    apache-airflow-providers-openlineage==2.20.0rc2

    PR #69109: Changes are working as expected with no observed regressions.

    apache-airflow-providers-snowflake==6.16.0rc1

    PR #69939: Changes are working as expected with no observed regressions.
26. potiuk commented on Aug 6, 2026

    

    potiuk

    on Aug 6, 2026

    MemberAuthor

    More actions

    PR moving both to 10.21.0: #71157

    It was not green to merge, so I did not want to merge it - It will get fixed in the future version.

    👍React with 👍1Reacted by Stefan Wang
27. potiuk commented on Aug 6, 2026

    

    potiuk

    on Aug 6, 2026

    MemberAuthor

    More actions

    Verified Opt-in concurrent pod creation in KubernetesExecutor on cncf-kubernetes 10.21.0rc1.

    Minor issue - The behavior is correct, but the RC ships a wrong versionadded on both new config options, which is my mistake. Details at the bottom. I do not think it blocks the release, see #71157.

    I did not want to wait for the PR to be red - we can fix it in doc release

    👍React with 👍1Reacted by Stefan Wang
28. fallintoplace commented on Aug 6, 2026

    

    fallintoplace

    on Aug 6, 2026

    Contributor

    More actions

    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.

    👍React with 👍1Reacted by Jarek Potiuk
29. potiuk commented on Aug 8, 2026

    

    potiuk

    on Aug 8, 2026

    MemberAuthor

    More actions

    this vote has been cancelled and restarted at #71246
30. potiuk

    closed this as completedon Aug 8, 2026