fix: end each psycopg2 persister call's transaction

[sangkyoonnam]

PostgreSQLPersister now commits or rolls back after is_initialized, list_app_ids, load and save, so one failed insert no longer breaks the persister for the rest of the process, and reads no longer leave a transaction open.

psycopg2 runs with autocommit off, so the first statement on the connection opens a transaction. save commits on success but doesn't roll back on failure. After a rejected insert, such as a duplicate (partition_key, app_id, sequence_id, position) or a state string with a NUL character, every later load, list_app_ids and save on that persister raises InFailedSqlTransaction. On main the repro is: save a row, save it again (UniqueViolation), then load the same app. AsyncPostgreSQLPersister isn't affected, since asyncpg doesn't open a transaction unless asked to.

load, list_app_ids and is_initialized never end their transaction, so the session sits in idle in transaction until the next save commits. created_at defaults to CURRENT_TIMESTAMP, which is the transaction start time, so that save is stamped with the time of the earlier read. With two connections, a read on A, a save on B, then a save on A stores A's row with an earlier created_at than B's, and load(partition_key, None) returns B's row as the latest.

Changes

• is_initialized, list_app_ids, load and save get their cursor from a small _transaction() context manager that commits on success and rolls back on any exception, KeyboardInterrupt included. If the rollback itself fails, usually because the connection is already gone, the original exception is the one raised. It doesn't use with self.connection:, because psycopg2 refuses to re-enter that from a caller's own with connection: block, and that pattern worked on main.
• The class docstring now names those four methods as ending their transaction and asks for a connection of the persister's own.
• list_app_ids maps a None partition key to PARTITION_KEY_DEFAULT in both PostgreSQLPersister and AsyncPostgreSQLPersister, as save and load already do, so list_app_ids(None) finds apps saved without a partition key instead of matching partition_key = NULL.
• _transaction() and create_table open their cursor with with self.connection.cursor() as cursor.
• Merged main to pick up fix: list each app once in SQL persister list_app_ids, newest save first #942; list_app_ids keeps its GROUP BY app_id ORDER BY MAX(created_at) DESC query inside _transaction().

How I tested this

• Eight new tests. Five cover the transaction boundaries: a duplicate save raises UniqueViolation and the next load, list_app_ids and save succeed; the connection reports TRANSACTION_STATUS_IDLE right after load (hit and miss), list_app_ids and an uncached is_initialized; a save on the fixture connection after a read and another connection's save gets a created_at at or after that save's; a KeyboardInterrupt raised by the cursor mid-call leaves the connection idle; and the persister still works inside a caller's with connection: block. Two check list_app_ids(None) after a save(None, ...) for each persister, and one records the cursors that is_initialized, save, load and list_app_ids open and checks that all four are closed. Against main with this test file, seven fail and 16 pass; all 23 pass here. The status checks are the deterministic ones; the created_at test relies on the server clock not going backwards.
• The Postgres tests ran against a local postgres:16 container with BURR_CI_INTEGRATION_TESTS=true, on fresh tables, from a copy of the test file with only the port changed: 23 passed.
• pytest tests --ignore=tests/integrations/persisters --ignore=tests/integrations/test_bip0042_bedrock.py: 687 passed, 3 skipped.
• pre-commit run on the changed files passes.

Notes

• Behavior change for the release notes: PostgreSQLPersister now ends its transaction after the database work in list_app_ids, load, save and an uncached is_initialized. Code that passes a connection it also uses itself is affected: a read now commits whatever that code had pending on the connection, a failed query now rolls back the whole transaction, and a load followed by a save no longer shares one transaction. save already committed pending work on main. Giving the persister a connection of its own keeps the caller's transactions separate.
• create_table doesn't go through _transaction(). It already commits, and a failed CREATE TABLE would still leave the transaction aborted; that seemed out of scope for this fix.
• I wrote this with Claude Code and reviewed and ran it myself.

Checklist

• PR has an informative and human-readable title (this will be pulled into the release notes)
• Changes are limited to a single goal (no scope creep)
• Code passed the pre-commit check & code is left cleaner/nicer than when first encountered.
• Any change in functionality is tested
• New functions are documented (with a description, list of inputs, and expected output)
• Placeholder code is flagged / future TODOs are captured in comments
• Project documentation has been updated if adding/changing functionality.

[elijahbenizzy]

Right fix, and it's parity with asyncpg. Three things before merge: rebase onto #942 once it lands (same list_app_ids body); while you're in list_app_ids, map a None partition key to PARTITION_KEY_DEFAULT for both psycopg2 and asyncpg, like save and load already do; and use 'with self.connection.cursor() as cursor' so cursors stop leaking. Please call out the shared-connection behavior change in the description for the release notes. Elijah

[sangkyoonnam]

@elijahbenizzy thanks, all four are in. I merged main rather than rebasing (f09c3ad), so the commits you reviewed stay as they are, and list_app_ids keeps #942's GROUP BY query. In b298509, list_app_ids maps None to PARTITION_KEY_DEFAULT in both persisters, and the psycopg2 cursors, create_table's included, are opened with with self.connection.cursor() as cursor. The shared-connection change now has its own paragraph under Notes, worded for the release notes.