Remove the sqlalchemy<2.1 cap in the Snowflake provider once snowflake-sqlalchemy supports SQLAlchemy 2.1

@potiuk

The Snowflake provider caps sqlalchemy>=1.4.54,<2.1 (added in #73822, the CI environment upgrade).

Why: snowflake-sqlalchemy up to 1.11.1, the latest stable release, subclasses sqlalchemy.orm.context.ORMSelectCompileState. SQLAlchemy 2.1 renamed that class to the private _ORMSelectCompileState, so import snowflake.sqlalchemy fails, and with it SnowflakeHook.get_uri() and the OpenLineage URI extraction. The only newer release, the pre-release 2.0.0rc2, itself declares sqlalchemy>=2.0.44,<2.1. Because the uv workspace has a single resolution, the cap also keeps the whole CI environment and constraints on SQLAlchemy 2.0.x.

Follow-up:

Once a snowflake-sqlalchemy release supports SQLAlchemy 2.1, raise the provider's snowflake-sqlalchemy floor to it and drop the <2.1 cap in providers/snowflake/pyproject.toml.
Regenerate uv.lock and check that the Snowflake hook tests (test_hook_should_support_prepare_basic_conn_params_and_uri) and operators/test_sql.py::test_execute_openlineage_events pass on SQLAlchemy 2.1.

Done when: the cap is removed and the Snowflake unit tests pass with SQLAlchemy 2.1 in the lock.

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

Fix CI breakages from the dependency upgrade

i will work on it

@potiuk

@potiuk I investigated #75118 and confirmed that snowflake-sqlalchemy 2.0.0 still declares sqlalchemy<2.1, so simply removing the cap would result in an incompatible dependency combination.

I found the cap in providers/snowflake/pyproject.toml on ci-upgrade-main. Should I investigate a workaround or upstream progress toward SQLAlchemy 2.1 compatibility, or would you prefer that I wait until a compatible release is available before proceeding?

[main] Upgrade important CI environment (#73822)

$ rm uv.lock && uv lock
error: No solution found when resolving dependencies for split (markers: python_full_version >= '3.16')
  cause: Because apache-airflow-core depends on sqlalchemy[asyncio]>=2.1.4 and apache-airflow-providers-snowflake depends on sqlalchemy>=1.4.54,<2.1, we can conclude that
         apache-airflow-providers-snowflake and apache-airflow-core[all] are incompatible.
         And because your workspace requires apache-airflow-core[all] and apache-airflow-providers-snowflake[common-ai], we can conclude that your workspace's
         requirements are unsatisfiable.

I think it's more correct to disable snowflake (thus giving its developers incentive to close a gap known for 8 months) than letting it hold all of Airflow back.

Thanks for the clarification. The resolver failure confirms that simply removing the SQLAlchemy cap is not sufficient while snowflake-sqlalchemy remains incompatible with SQLAlchemy 2.1.

I can investigate whether Snowflake can be excluded from the affected CI dependency-resolution split while preserving its existing provider constraints and tests in compatible environments.

Before proceeding, could you confirm whether you'd like me to implement this CI-level exclusion, or whether you have a preferred approach for handling providers that currently block the SQLAlchemy 2.1 upgrade?

Navigation Menu

Repository navigation

Remove the sqlalchemy<2.1 cap in the Snowflake provider once snowflake-sqlalchemy supports SQLAlchemy 2.1 #75118

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Remove the sqlalchemy<2.1 cap in the Snowflake provider once snowflake-sqlalchemy supports SQLAlchemy 2.1 #75118

Description

Activity

abhijeets25012-tech commented on Oct 19, 2026

abhijeets25012-tech commented on Oct 20, 2026

Dev-iL commented on Oct 20, 2026

abhijeets25012-tech commented on Oct 20, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions