Skip to content

Compatibility with SQLA2.1#61229

Draft
Dev-iL wants to merge 3 commits into
apache:mainfrom
Dev-iL:2601/sqla2.1_compat
Draft

Compatibility with SQLA2.1#61229
Dev-iL wants to merge 3 commits into
apache:mainfrom
Dev-iL:2601/sqla2.1_compat

Conversation

@Dev-iL

@Dev-iL Dev-iL commented Jan 29, 2026

Copy link
Copy Markdown
Collaborator

This PR is intended to ensure compatibility with SQLA2.1.

The plan is as follows:


Was generative AI tooling used to co-author this PR?
  • Yes (please specify the tool below)

  • Read the Pull Request Guidelines for more information. Note: commit author/co-author name and email in commits become permanently public when merged.
  • For fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
  • When adding dependency, check compliance with the ASF 3rd Party License Policy.
  • For significant user-facing changes create newsfragment: {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

@Dev-iL Dev-iL marked this pull request as draft January 29, 2026 20:13
@Dev-iL Dev-iL added full tests needed We need to run full set of tests for this PR to merge all versions If set, the CI build will be forced to use all versions of Python/K8S/DBs labels Jan 29, 2026
@Dev-iL Dev-iL closed this Jan 29, 2026
@Dev-iL Dev-iL reopened this Jan 29, 2026
@Dev-iL

Dev-iL commented Jan 30, 2026

Copy link
Copy Markdown
Collaborator Author

According to an old discussion in the SQLA repo,

It seems that sqlalchemy_utils is using an internal api in an unsupported way.

In SQLA2.1 this api was finally marked as private and sqlalchemy-utils broke . I believe these are the options we have:

  1. Move away from sqlalchmy-utils.
  2. Get sqlalchmy-utils fixed.
  3. Restrict the SQLA version to <2.1 until one of the above happens.

Thoughts?

@potiuk

potiuk commented Jan 30, 2026

Copy link
Copy Markdown
Member

Thanks for runnig it @Dev-iL -> really cool you are doing it !

Move away from sqlalchmy-utils.

We only seem to use sqlalchmy_utils for UUIDtype

from sqlalchemy_utils import UUIDType

I guess in sqlalchemy 2.+ there should be already an alternative type we can use ?

https://docs.sqlalchemy.org/en/21/core/custom_types.html#backend-agnostic-guid-type

Since version 2.0 the built-in Uuid type that behaves similarly should be preferred. This example is presented just as an example of a type decorator that receives and returns python objects.

Not sure about compatibility, but I would imagine it should be quite easy to replace it

@Dev-iL

Dev-iL commented Jan 30, 2026

Copy link
Copy Markdown
Collaborator Author

@potiuk Thanks for the tip! I think we might be able to remove both of these dependencies: sqlalchemy-jsonfield and sqlalchemy-utils.

@Dev-iL Dev-iL force-pushed the 2601/sqla2.1_compat branch from 02201e3 to 1fcfcb9 Compare February 5, 2026 07:14
@Dev-iL

Dev-iL commented Feb 5, 2026

Copy link
Copy Markdown
Collaborator Author

@jscheffl Do you see any issue with modifying the old migrations so we can move to new ORM type hints? The DB should stay the same (if I did everything right).

The SQLA docs mention that:

To have the Uuid datatype work with string-based Uuids (e.g. 32 character hexadecimal strings), pass the Uuid.as_uuid parameter with the value False.

So here's what I think:

  • Step 1: Whenever a uuid is treated as a string we should have sa.Uuid(as_uuid=False) in old migrations.
  • Step 2: Create a new migration that converts all of these fields into "native" Uuids (i.e. sa.Uuid(as_uuid=True) and update the ORM accordingly.

@jscheffl

jscheffl commented Feb 5, 2026

Copy link
Copy Markdown
Contributor

@jscheffl Do you see any issue with modifying the old migrations so we can move to new ORM type hints? The DB should stay the same (if I did everything right).

I do not see an issue in this except (1) testing and (2) review. But all looks like simple subsitutes. So OK for me.

@Dev-iL

Dev-iL commented Feb 5, 2026

Copy link
Copy Markdown
Collaborator Author

I do not see an issue in this except (1) testing and (2) review.

How to test this besides adding the full tests needed tag?

@jscheffl

jscheffl commented Feb 5, 2026

Copy link
Copy Markdown
Contributor

I do not see an issue in this except (1) testing and (2) review.

How to test this besides adding the full tests needed tag?

Mhm, yeah taking a Airflow 2.7.0 setup and run the migration :-) Such integrative tests are not in CI in my view.

@Dev-iL

Dev-iL commented Feb 5, 2026

Copy link
Copy Markdown
Collaborator Author

Mhm, yeah taking a Airflow 2.7.0 setup and run the migration :-) Such integrative tests are not in CI in my view.

Isn't that what the migration tests (e.g. this) do?

@jscheffl

jscheffl commented Feb 5, 2026

Copy link
Copy Markdown
Contributor

Mhm, yeah taking a Airflow 2.7.0 setup and run the migration :-) Such integrative tests are not in CI in my view.

Isn't that what the migration tests (e.g. this) do?

Ah... yeah ... 🤦

@Dev-iL Dev-iL force-pushed the 2601/sqla2.1_compat branch 2 times, most recently from 0033892 to 214c5c4 Compare February 26, 2026 05:05
@Dev-iL Dev-iL force-pushed the 2601/sqla2.1_compat branch from 214c5c4 to 26174d5 Compare March 2, 2026 11:59
@Dev-iL Dev-iL force-pushed the 2601/sqla2.1_compat branch from 26174d5 to a88ad9e Compare March 17, 2026 11:48
Dev-iL added a commit to Dev-iL/airflow that referenced this pull request Mar 26, 2026
SQLAlchemy 2.1 deprecated the `noload` lazy loading strategy
(sqlalchemy/sqlalchemy#11045). `noload` silently returns `None`/empty
collections — essentially incorrect results — and will be removed in a
future release.

This PR replaces all 5 occurrences of `lazy="noload"` with `lazy="raise"`,
which raises `InvalidRequestError` if the relationship is accessed without
an explicit eager load (e.g. `joinedload`). All affected relationships are
already properly loaded via `joinedload()` wherever they're accessed, so
this is a safe drop-in that also catches missing eager loads at development
time instead of silently returning `None`.

Two callers needed fixes to work correctly with `lazy="raise"`:
- `TaskInstance.rendered_task_instance_fields` and `TaskInstance.hitl_detail`
  needed `passive_deletes=True` to tell SQLAlchemy to rely on the DB-level
  `ON DELETE CASCADE` rather than attempting ORM-level cascade processing
  (which would fail since FK columns are also PK columns on RTIF, and
  `lazy="raise"` prevents the ORM from loading the collection to clear them).
- The HITL API endpoints needed `joinedload(TI.rendered_task_instance_fields)`
  added to their queries, since `TaskInstanceResponse` accesses
  `rendered_task_instance_fields` during Pydantic serialization. The
  `get_hitl_detail` endpoint also needed an explicit `model_validate()` call
  so serialization happens while the session is still active.

**Changed models:**
- `Log.task_instance`
- `TaskInstance.rendered_task_instance_fields`
- `TaskInstance.hitl_detail`
- `TaskInstanceHistory.hitl_detail`
- `XComModel.task`

related: apache#61229
Dev-iL added a commit to Dev-iL/airflow that referenced this pull request Mar 27, 2026
SQLAlchemy 2.1 deprecated the `noload` lazy loading strategy
(sqlalchemy/sqlalchemy#11045). `noload` silently returns `None`/empty
collections — essentially incorrect results — and will be removed in a
future release.

This PR replaces all 5 occurrences of `lazy="noload"` with `lazy="raise"`,
which raises `InvalidRequestError` if the relationship is accessed without
an explicit eager load (e.g. `joinedload`). All affected relationships are
already properly loaded via `joinedload()` wherever they're accessed, so
this is a safe drop-in that also catches missing eager loads at development
time instead of silently returning `None`.

Two callers needed fixes to work correctly with `lazy="raise"`:
- `TaskInstance.rendered_task_instance_fields` and `TaskInstance.hitl_detail`
  needed `passive_deletes=True` to tell SQLAlchemy to rely on the DB-level
  `ON DELETE CASCADE` rather than attempting ORM-level cascade processing
  (which would fail since FK columns are also PK columns on RTIF, and
  `lazy="raise"` prevents the ORM from loading the collection to clear them).
- The HITL API endpoints needed `joinedload(TI.rendered_task_instance_fields)`
  added to their queries, since `TaskInstanceResponse` accesses
  `rendered_task_instance_fields` during Pydantic serialization. The
  `get_hitl_detail` endpoint also needed an explicit `model_validate()` call
  so serialization happens while the session is still active.

**Changed models:**
- `Log.task_instance`
- `TaskInstance.rendered_task_instance_fields`
- `TaskInstance.hitl_detail`
- `TaskInstanceHistory.hitl_detail`
- `XComModel.task`

related: apache#61229
Dev-iL added a commit to Dev-iL/airflow that referenced this pull request Mar 27, 2026
SQLAlchemy 2.1 deprecated the `noload` lazy loading strategy
(sqlalchemy/sqlalchemy#11045). `noload` silently returns `None`/empty
collections — essentially incorrect results — and will be removed in a
future release.

This PR replaces all 5 occurrences of `lazy="noload"` with `lazy="raise"`,
which raises `InvalidRequestError` if the relationship is accessed without
an explicit eager load (e.g. `joinedload`). All affected relationships are
already properly loaded via `joinedload()` wherever they're accessed, so
this is a safe drop-in that also catches missing eager loads at development
time instead of silently returning `None`.

Two callers needed fixes to work correctly with `lazy="raise"`:
- `TaskInstance.rendered_task_instance_fields` and `TaskInstance.hitl_detail`
  needed `passive_deletes=True` to tell SQLAlchemy to rely on the DB-level
  `ON DELETE CASCADE` rather than attempting ORM-level cascade processing
  (which would fail since FK columns are also PK columns on RTIF, and
  `lazy="raise"` prevents the ORM from loading the collection to clear them).
- The HITL API endpoints needed `joinedload(TI.rendered_task_instance_fields)`
  added to their queries, since `TaskInstanceResponse` accesses
  `rendered_task_instance_fields` during Pydantic serialization. The
  `get_hitl_detail` endpoint also needed an explicit `model_validate()` call
  so serialization happens while the session is still active.

**Changed models:**
- `Log.task_instance`
- `TaskInstance.rendered_task_instance_fields`
- `TaskInstance.hitl_detail`
- `TaskInstanceHistory.hitl_detail`
- `XComModel.task`

related: apache#61229
Dev-iL added a commit to Dev-iL/airflow that referenced this pull request Mar 27, 2026
SQLAlchemy 2.1 deprecated the `noload` lazy loading strategy
(sqlalchemy/sqlalchemy#11045). `noload` silently returns `None`/empty
collections — essentially incorrect results — and will be removed in a
future release.

This PR replaces all 5 occurrences of `lazy="noload"` with `lazy="raise"`,
which raises `InvalidRequestError` if the relationship is accessed without
an explicit eager load (e.g. `joinedload`). All affected relationships are
already properly loaded via `joinedload()` wherever they're accessed, so
this is a safe drop-in that also catches missing eager loads at development
time instead of silently returning `None`.

Two callers needed fixes to work correctly with `lazy="raise"`:
- `TaskInstance.rendered_task_instance_fields` and `TaskInstance.hitl_detail`
  needed `passive_deletes=True` to tell SQLAlchemy to rely on the DB-level
  `ON DELETE CASCADE` rather than attempting ORM-level cascade processing
  (which would fail since FK columns are also PK columns on RTIF, and
  `lazy="raise"` prevents the ORM from loading the collection to clear them).
- The HITL API endpoints needed `joinedload(TI.rendered_task_instance_fields)`
  added to their queries, since `TaskInstanceResponse` accesses
  `rendered_task_instance_fields` during Pydantic serialization. The
  `get_hitl_detail` endpoint also needed an explicit `model_validate()` call
  so serialization happens while the session is still active.

**Changed models:**
- `Log.task_instance`
- `TaskInstance.rendered_task_instance_fields`
- `TaskInstance.hitl_detail`
- `TaskInstanceHistory.hitl_detail`
- `XComModel.task`

related: apache#61229
Dev-iL added a commit to Dev-iL/airflow that referenced this pull request Mar 27, 2026
SQLAlchemy 2.1 deprecated the `noload` lazy loading strategy
(sqlalchemy/sqlalchemy#11045). `noload` silently returns `None`/empty
collections — essentially incorrect results — and will be removed in a
future release.

This PR replaces all 5 occurrences of `lazy="noload"` with `lazy="raise"`,
which raises `InvalidRequestError` if the relationship is accessed without
an explicit eager load (e.g. `joinedload`). All affected relationships are
already properly loaded via `joinedload()` wherever they're accessed, so
this is a safe drop-in that also catches missing eager loads at development
time instead of silently returning `None`.

Two callers needed fixes to work correctly with `lazy="raise"`:
- `TaskInstance.rendered_task_instance_fields` and `TaskInstance.hitl_detail`
  needed `passive_deletes=True` to tell SQLAlchemy to rely on the DB-level
  `ON DELETE CASCADE` rather than attempting ORM-level cascade processing
  (which would fail since FK columns are also PK columns on RTIF, and
  `lazy="raise"` prevents the ORM from loading the collection to clear them).
- The HITL API endpoints needed `joinedload(TI.rendered_task_instance_fields)`
  added to their queries, since `TaskInstanceResponse` accesses
  `rendered_task_instance_fields` during Pydantic serialization. The
  `get_hitl_detail` endpoint also needed an explicit `model_validate()` call
  so serialization happens while the session is still active.

**Changed models:**
- `Log.task_instance`
- `TaskInstance.rendered_task_instance_fields`
- `TaskInstance.hitl_detail`
- `TaskInstanceHistory.hitl_detail`
- `XComModel.task`

related: apache#61229
jscheffl pushed a commit that referenced this pull request Mar 28, 2026
)

SQLAlchemy 2.1 deprecated the `noload` lazy loading strategy
(sqlalchemy/sqlalchemy#11045). `noload` silently returns `None`/empty
collections — essentially incorrect results — and will be removed in a
future release.

This PR replaces all 5 occurrences of `lazy="noload"` with `lazy="raise"`,
which raises `InvalidRequestError` if the relationship is accessed without
an explicit eager load (e.g. `joinedload`). All affected relationships are
already properly loaded via `joinedload()` wherever they're accessed, so
this is a safe drop-in that also catches missing eager loads at development
time instead of silently returning `None`.

Two callers needed fixes to work correctly with `lazy="raise"`:
- `TaskInstance.rendered_task_instance_fields` and `TaskInstance.hitl_detail`
  needed `passive_deletes=True` to tell SQLAlchemy to rely on the DB-level
  `ON DELETE CASCADE` rather than attempting ORM-level cascade processing
  (which would fail since FK columns are also PK columns on RTIF, and
  `lazy="raise"` prevents the ORM from loading the collection to clear them).
- The HITL API endpoints needed `joinedload(TI.rendered_task_instance_fields)`
  added to their queries, since `TaskInstanceResponse` accesses
  `rendered_task_instance_fields` during Pydantic serialization. The
  `get_hitl_detail` endpoint also needed an explicit `model_validate()` call
  so serialization happens while the session is still active.

**Changed models:**
- `Log.task_instance`
- `TaskInstance.rendered_task_instance_fields`
- `TaskInstance.hitl_detail`
- `TaskInstanceHistory.hitl_detail`
- `XComModel.task`

related: #61229
nailo2c pushed a commit to nailo2c/airflow that referenced this pull request Mar 30, 2026
…che#64262)

SQLAlchemy 2.1 deprecated the `noload` lazy loading strategy
(sqlalchemy/sqlalchemy#11045). `noload` silently returns `None`/empty
collections — essentially incorrect results — and will be removed in a
future release.

This PR replaces all 5 occurrences of `lazy="noload"` with `lazy="raise"`,
which raises `InvalidRequestError` if the relationship is accessed without
an explicit eager load (e.g. `joinedload`). All affected relationships are
already properly loaded via `joinedload()` wherever they're accessed, so
this is a safe drop-in that also catches missing eager loads at development
time instead of silently returning `None`.

Two callers needed fixes to work correctly with `lazy="raise"`:
- `TaskInstance.rendered_task_instance_fields` and `TaskInstance.hitl_detail`
  needed `passive_deletes=True` to tell SQLAlchemy to rely on the DB-level
  `ON DELETE CASCADE` rather than attempting ORM-level cascade processing
  (which would fail since FK columns are also PK columns on RTIF, and
  `lazy="raise"` prevents the ORM from loading the collection to clear them).
- The HITL API endpoints needed `joinedload(TI.rendered_task_instance_fields)`
  added to their queries, since `TaskInstanceResponse` accesses
  `rendered_task_instance_fields` during Pydantic serialization. The
  `get_hitl_detail` endpoint also needed an explicit `model_validate()` call
  so serialization happens while the session is still active.

**Changed models:**
- `Log.task_instance`
- `TaskInstance.rendered_task_instance_fields`
- `TaskInstance.hitl_detail`
- `TaskInstanceHistory.hitl_detail`
- `XComModel.task`

related: apache#61229
Suraj-kumar00 pushed a commit to Suraj-kumar00/airflow that referenced this pull request Apr 7, 2026
…che#64262)

SQLAlchemy 2.1 deprecated the `noload` lazy loading strategy
(sqlalchemy/sqlalchemy#11045). `noload` silently returns `None`/empty
collections — essentially incorrect results — and will be removed in a
future release.

This PR replaces all 5 occurrences of `lazy="noload"` with `lazy="raise"`,
which raises `InvalidRequestError` if the relationship is accessed without
an explicit eager load (e.g. `joinedload`). All affected relationships are
already properly loaded via `joinedload()` wherever they're accessed, so
this is a safe drop-in that also catches missing eager loads at development
time instead of silently returning `None`.

Two callers needed fixes to work correctly with `lazy="raise"`:
- `TaskInstance.rendered_task_instance_fields` and `TaskInstance.hitl_detail`
  needed `passive_deletes=True` to tell SQLAlchemy to rely on the DB-level
  `ON DELETE CASCADE` rather than attempting ORM-level cascade processing
  (which would fail since FK columns are also PK columns on RTIF, and
  `lazy="raise"` prevents the ORM from loading the collection to clear them).
- The HITL API endpoints needed `joinedload(TI.rendered_task_instance_fields)`
  added to their queries, since `TaskInstanceResponse` accesses
  `rendered_task_instance_fields` during Pydantic serialization. The
  `get_hitl_detail` endpoint also needed an explicit `model_validate()` call
  so serialization happens while the session is still active.

**Changed models:**
- `Log.task_instance`
- `TaskInstance.rendered_task_instance_fields`
- `TaskInstance.hitl_detail`
- `TaskInstanceHistory.hitl_detail`
- `XComModel.task`

related: apache#61229
@kaxil kaxil requested a review from Copilot April 10, 2026 19:55

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Updates CI and tests to accommodate SQLAlchemy 2.1 pre-release installs, while working around known incompatibilities in snowflake-sqlalchemy.

Changes:

  • Force-install SQLAlchemy 2.1 pre-release and snowflake-sqlalchemy from Git main in “upgrade SQLAlchemy” CI paths.
  • Skip/ignore Snowflake-related tests when snowflake-sqlalchemy breaks under SQLAlchemy 2.1.
  • Filter/skip known failing import errors in DAG serialization and example DAG import tests.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 5 comments.

Show a summary per file
File Description
scripts/docker/entrypoint_ci.sh Adds prerelease SQLAlchemy + git snowflake-sqlalchemy install step in upgrade check.
Dockerfile.ci Mirrors the CI install step for SQLAlchemy 2.1 prerelease + git snowflake-sqlalchemy.
providers/snowflake/tests/conftest.py Ignores Snowflake provider tests when snowflake-sqlalchemy import fails under SQLA 2.1.
providers/common/sql/tests/unit/common/sql/operators/test_sql.py Skips Snowflake-specific tests when snowflake-sqlalchemy is incompatible/unimportable.
airflow-core/tests/unit/serialization/test_dag_serialization.py Filters a known Snowflake/SQLA 2.1 import error from assertions.
airflow-core/tests/unit/always/test_example_dags.py Skips example DAG import checks when Snowflake/SQLA mismatch causes a known error.

echo
uv sync --all-packages --no-install-package apache-airflow-providers-fab --resolution highest \
--no-python-downloads --no-managed-python
uv pip install "sqlalchemy>=2.1.0b1" "snowflake-sqlalchemy @ git+https://github.com/snowflakedb/snowflake-sqlalchemy.git@main" --prerelease=allow

Copilot AI Apr 10, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Installing snowflake-sqlalchemy from git@main makes CI non-deterministic (breakages can appear without changes in this repo). Consider pinning to a specific commit SHA (or a released version once available) and adding an upper-bound for SQLAlchemy (e.g. <2.2) so the job doesn’t silently start testing 2.2+ later.

Suggested change
uv pip install "sqlalchemy>=2.1.0b1" "snowflake-sqlalchemy @ git+https://github.com/snowflakedb/snowflake-sqlalchemy.git@main" --prerelease=allow
uv pip install "sqlalchemy>=2.1.0b1,<2.2" "snowflake-sqlalchemy @ git+https://github.com/snowflakedb/snowflake-sqlalchemy.git@3f5a6c7d8e9f0123456789abcdef0123456789ab" --prerelease=allow

Copilot uses AI. Check for mistakes.
Comment thread Dockerfile.ci
echo
uv sync --all-packages --no-install-package apache-airflow-providers-fab --resolution highest \
--no-python-downloads --no-managed-python
uv pip install "sqlalchemy>=2.1.0b1" "snowflake-sqlalchemy @ git+https://github.com/snowflakedb/snowflake-sqlalchemy.git@main" --prerelease=allow

Copilot AI Apr 10, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same concern as in entrypoint_ci.sh: pulling snowflake-sqlalchemy from main makes builds flaky/non-reproducible. Pin to a commit SHA (or released version) and consider bounding SQLAlchemy to the 2.1 line (e.g. <2.2) to keep the job purpose stable over time.

Suggested change
uv pip install "sqlalchemy>=2.1.0b1" "snowflake-sqlalchemy @ git+https://github.com/snowflakedb/snowflake-sqlalchemy.git@main" --prerelease=allow
uv pip install "sqlalchemy>=2.1.0b1,<2.2" "snowflake-sqlalchemy==1.7.5" --prerelease=allow

Copilot uses AI. Check for mistakes.
# snowflake-sqlalchemy does not yet support SQLAlchemy 2.1
try:
from snowflake.sqlalchemy import URL # noqa: F401
except AttributeError:

Copilot AI Apr 10, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

from snowflake.sqlalchemy import URL will raise ImportError if URL is not present (or the module layout changes), not only AttributeError. To avoid collection-time crashes in those cases, catch (ImportError, AttributeError) (or Exception only if you can justify it) before setting collect_ignore_glob.

Suggested change
except AttributeError:
except (ImportError, AttributeError):

Copilot uses AI. Check for mistakes.
Comment on lines +219 to +223
# snowflake-sqlalchemy does not yet support SQLAlchemy 2.1
if len(dagbag.import_errors) == 1 and "ORMSelectCompileState" in str(dagbag.import_errors):
pytest.skip(
f"Skipping {example} because snowflake-sqlalchemy is incompatible with installed SQLAlchemy."
)

Copilot AI Apr 10, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

dagbag.import_errors is typically a mapping; checking \"ORMSelectCompileState\" in str(dagbag.import_errors) is brittle and len(...) == 1 can miss the targeted failure when additional import errors exist. Prefer checking the actual error messages (e.g., any value contains the substring) and don’t require exactly one import error.

Copilot uses AI. Check for mistakes.
for ignore_module_import_error in IGNORE_MODULE_IMPORT_ERRORS
)
# snowflake-sqlalchemy does not yet support SQLAlchemy 2.1
if "module 'sqlalchemy.orm.context' has no attribute 'ORMSelectCompileState'" not in error

Copilot AI Apr 10, 2026

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Filtering by the full, exact error string is fragile across SQLAlchemy/snowflake-sqlalchemy versions (minor wording changes will re-break the test). Consider matching on a stable substring (e.g. ORMSelectCompileState) or a structured signal (exception type/module) if available in error.

Suggested change
if "module 'sqlalchemy.orm.context' has no attribute 'ORMSelectCompileState'" not in error
if "ORMSelectCompileState" not in error

Copilot uses AI. Check for mistakes.
@Dev-iL Dev-iL force-pushed the 2601/sqla2.1_compat branch from a88ad9e to 5d42c11 Compare April 16, 2026 20:54
@Dev-iL

Dev-iL commented Apr 16, 2026

Copy link
Copy Markdown
Collaborator Author

2.1.0b2 was just released.

@Dev-iL Dev-iL force-pushed the 2601/sqla2.1_compat branch from 5d42c11 to f4084e4 Compare April 22, 2026 14:48
@potiuk

potiuk commented Jun 4, 2026

Copy link
Copy Markdown
Member

@Dev-iL This draft PR has had no activity for 7 weeks. Closing to keep the queue clean.

You are welcome to reopen and continue when you're ready. If you'd like to pick it back up, please rebase onto the current main branch first.


Note: This comment was drafted by an AI-assisted triage tool and may contain mistakes. Once you resume work, an Apache Airflow maintainer — a real person — will take the next look at your PR. We use this two-stage triage process so that our maintainers' limited time is spent where it matters most: the conversation with you.

@potiuk potiuk closed this Jun 4, 2026
@Dev-iL Dev-iL reopened this Jun 4, 2026
Dev-iL added 3 commits June 3, 2026 21:06
- Ignore import error in `TestStringifiedDAGs`, `TestSQLCheckOperatorDbHook`, and `test_should_be_importable`.
- Skip all snowflake provider tests (since the foundational `SnowflakeHook` is not importable).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

all versions If set, the CI build will be forced to use all versions of Python/K8S/DBs area:dev-tools full tests needed We need to run full set of tests for this PR to merge

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants