File transactions retain one native SQLite handle per terminal operation

Version

• @libsql/client 0.15.15
• libsql 0.5.29
• macOS arm64, Node 22 and 25

Reproduction

A file-backed client is flat under repeated direct client.execute(...) calls. Repeating client.transaction() followed by a bound statement and commit, rollback, or close retains one main database handle and one WAL handle per transaction. After 100 mixed terminal operations, lsof reports 100 main and 100 WAL handles; client.close() does not release them.

The transaction implementation detaches the current Database by assigning the client field to null and returns Sqlite3Transaction. That transaction ends SQL state but never closes the detached Database.

A minimal patch that makes all three terminal paths converge on one idempotent Database.close() call still retains the handles. The reason is the lower libsql prepared-statement lifetime: after a statement has executed, Database.close() changes open to false but the native file handle remains until GC. A database used only through Database.exec() closes immediately.

Expected

Every transaction terminal operation releases its detached native database deterministically. A subsequent client.close() leaves no transaction-owned native handles, without requiring GC.

Exit trigger for downstream patch

A released @libsql/client plus supported libsql dependency combination passes a 100-transaction mixed commit/rollback/close regression with FD samples at 0/1/10/25/50/100 plateauing within the warm-up count, while the direct-execute control remains flat.

Start at the transaction implementation that detaches the current Database and at the lower libsql Database.close() behavior after prepared-statement execution. Reproduce the 100-transaction mixed commit/rollback/close case and compare file-descriptor samples with the direct-execute control. Done means supported dependency versions release transaction-owned handles without requiring GC.