I think transaction_async was ported to async from similar synchronous code. But it looks to me like it's not cancel-safe because if it is cancelled at this await point then we will wind up having executed BEGIN TRANSACTION; and then putting the connection back in the pool. The result of this is surprisingly terrible: any future operation (using transaction_async() or not) may wind up getting this connection, and it may wind up successfully executing any number of SQL statements (including UPDATEs and SELECTs) that appear to work normally, but none of the changes are reflected in the database because they're being made in a not-yet-committed transaction. This can go on indefinitely -- any number of statements over any amount of time. The connection is essentially "poisoned" in a way that updates are going to /dev/null except that reads (on this one connection only) do reflect those changes.

I have reproduced this with a (relatively) simple demo.