Failed BEGIN leaves Connection._top_xact set; every later transaction becomes a SAVEPOINT and fails with NoActiveSQLTransactionError
Maintainer thường phản hồi trong vòng 1 ngày
Đánh giá
- Độ khó
- 2/5
- Thời gian dự kiến
- 1-3 giờ
- Mức phù hợp với người mới
- 35/100
Hướng nghiên cứu
Read Transaction.start() and the transaction tests in tests/test_transaction.py, focusing on the path where BEGIN raises. Check the existing cleanup in __commit() and __rollback() and add coverage for a failed BEGIN, including the nested-savepoint case. Done means the connection can start a later transaction after a failed BEGIN without leaving an outer transaction’s state corrupted; linked pull request #1387 is already open.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
Summary
Transaction.start() assigns con._top_xact = self before it sends BEGIN. If BEGIN raises, the transaction is marked FAILED, but _top_xact is never reset. From then on, every conn.transaction() on that connection is treated as nested and sends SAVEPOINT ..., which the server rejects:
asyncpg.exceptions.NoActiveSQLTransactionError: SAVEPOINT can only be used in transaction blocks
The connection is still open and idle (is_closed() == False, is_in_transaction() == False), but it cannot run a transaction again until it is closed or reset().
Reproduction
The concurrent query below is just a convenient way to make BEGIN raise. Any exception from BEGIN has the same effect (see "How we hit it").
import asyncio
import asyncpg
async def main():
conn = await asyncpg.connect("postgresql://postgres:postgres@localhost:5432/postgres")
# Make BEGIN fail: the connection is busy, so execute("BEGIN") raises before sending anything.
busy = asyncio.create_task(conn.execute("SELECT pg_sleep(0.5)"))
await asyncio.sleep(0.1)
try:
await conn.transaction().start()
except asyncpg.InterfaceError as e:
print("BEGIN failed:", e)
await busy
print("is_in_transaction:", conn.is_in_transaction(), "| _top_xact:", conn._top_xact)
async with conn.transaction(): # sent as SAVEPOINT -> NoActiveSQLTransactionError
await conn.execute("SELECT 1")
asyncio.run(main())
BEGIN failed: cannot perform operation: another operation is in progress
is_in_transaction: False | _top_xact: <asyncpg.Transaction state:failed 0x...>
asyncpg.exceptions.NoActiveSQLTransactionError: SAVEPOINT can only be used in transaction blocks
How we hit it
We run Aurora PostgreSQL behind Amazon RDS Proxy, with SQLAlchemy 2.0's asyncpg dialect. RDS Proxy could not borrow a backend connection in time, answered BEGIN with an error (SQLSTATE 08000) and kept the client socket open:
03:00:03 PostgresConnectionError: Timed-out waiting to acquire database connection.
03:00:05 NoActiveSQLTransactionError: SAVEPOINT can only be used in transaction blocks
03:00:07 NoActiveSQLTransactionError: SAVEPOINT can only be used in transaction blocks
... (every write until the process was restarted)
asyncpg.Pool clears it on release(), which calls Connection._reset() and resets _top_xact. Until then, retries within the same acquire() fail the same way. Connections reused without reset(), such as SQLAlchemy's pool or a long-lived connection, stay broken until they are closed.
Is this intentional? We couldn't tell whether leaving _top_xact set after a failed BEGIN is by design. The tests in tests/test_transaction.py assert _top_xact is None after every error case they cover, but none covers BEGIN itself failing.
Proposed fix
In Transaction.start():
try:
await self._connection.execute(query)
except BaseException:
self._state = TransactionState.FAILED
+ if con._top_xact is self:
+ con._top_xact = None
raise
This mirrors what __commit() and __rollback() already do. The is self guard leaves the outer transaction in place when a nested SAVEPOINT fails.
Why this is safe for any exception
Only __commit() and __rollback() clear _top_xact, and both raise for a FAILED transaction before reaching that line. So after a failed BEGIN, nothing can ever release it, whatever the exception was. Whether the server is actually in a transaction is tracked separately, through is_in_transaction(), and start() already checks that when _top_xact is None:
How BEGIN failed |
Server afterwards | Today | With the fix |
|---|---|---|---|
Error response (e.g. the proxy's 08000) |
not in a transaction | every later transaction fails with 25P01 |
next BEGIN works |
| Raised before sending (e.g. the repro above) | not in a transaction | same | next BEGIN works |
Cancelled after the server ran BEGIN |
in a transaction | next transaction becomes a SAVEPOINT in that open transaction, reports success, but nothing is committed |
if the reply to the cancelled BEGIN has been read: InterfaceError: cannot use Connection.transaction() in a manually started transaction; if not yet: BEGIN is sent again (the server only warns) and the transaction commits normally |
Environment
- asyncpg 0.32.0 (also 0.31.0)
- PostgreSQL 17 (repro); Aurora PostgreSQL behind RDS Proxy (production)
- Python 3.14
- Ngôn ngữ chính
- Python
- Star
- 8.1k
- Fork
- 474
- Merge trung bình
- 1 ngày 17 giờ
- Pull request đã merge (30 ngày)
- 24
Chuẩn bị môi trường
Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của MagicStack/asyncpg
-
Connect call failed error doesn't distinguish port mismatch from "server not running"Có thể đã có người làm @aryansk đã nhận 57 ngày trước. Đang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 72/100
MagicStack/asyncpg#1342 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
TypeError in asyncpg.connect() for specific parameters when values are not str enoughCó thể đã có người làm @pranjalm37 đã nhận 59 ngày trước. Đang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 56/100
MagicStack/asyncpg#1340 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
setup.py relies on deprecated pkg_resourcesCó thể đã có người làm @jasonwbarnett đã nhận 88 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 28/100
MagicStack/asyncpg#1337 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 42/100
MagicStack/asyncpg#1330 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 5/5 Hơn một tuần Mức phù hợp với người mới 38/100
MagicStack/asyncpg#1322 · 1 bình luận ·
Maintainer thường phản hồi trong vòng 1 ngày
Tất cả issue của MagicStack/asyncpg
Issue tương tự
-
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 82/100
esphome/esphome.io#7657 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
comp/gateway comp/plugins duplicate P3 type/bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 82/100
NousResearch/hermes-agent#137019 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 72/100
Maintainer thường phản hồi trong vòng 1 ngày
-
Kumo-Tabular weights unreachable behind restrictive egress proxies (Xet + plain HTTP both fail)Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 67/100
NVIDIA/structured-data-models#1091 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
[work-item] adam-adae-worsening-emergence: conform spec.yaml to the specification style contract (REQ-1280)Có thể đã có người làm @muse-yamaa-bot đã nhận hôm nay. Đang mởwork-item
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 82/100
Maintainer thường phản hồi trong vòng 1 ngày