[CaffeinatedCoder]

What was wrong

BLiteSession.Rollback() started CurrentTransaction.RollbackAsync() and returned without awaiting the ValueTask (#307, BLiteSession.cs:107-116). The session forgot the transaction at once, but the rollback finished later: the abort record was written to the WAL, then the transaction became Aborted and its rollback handlers restored the collection's free-space index. Any exception from that work was lost. The README's session sample uses this call in its catch block.

Measured with the new test (300 rollbacks while another task commits to a second collection): 236–244 of 300 transactions were still Active when Rollback() had returned.

Fix

• BLiteSession.RollbackAsync() (new) awaits the rollback. It forgets the transaction before the rollback starts, so a second Rollback/RollbackAsync or a CommitAsync on the same session cannot act on a transaction that is already rolling back. It takes no CancellationToken, like ITransaction.RollbackAsync(): a rollback is not something to abandon halfway.
• Rollback() blocks on it (GetAwaiter().GetResult()), the pattern Transaction.Dispose already uses for the same call. Its XML doc now says so and points at RollbackAsync.
• The generated typed session wrapper (OpenTypedSession) gets RollbackAsync() next to Rollback().
• README session sample: await session.RollbackAsync();.

Not changed: BLiteEngine.Rollback() stays the documented no-op. Removing both synchronous methods is for v6 (#296). The blocking Rollback() is one more synchronous wait of the kind #290 lists for the browser runtime; RollbackAsync is the one to use there.

Tests

BLiteSessionTests, five new tests:

Test	upstream/main	this PR
RollbackAsync_TransactionIsAborted_WhenItReturns (300 rollbacks under a concurrent committer)	fails, 300 of 300 still active (with a fire-and-forget shim for the new method)	passes
Rollback_TransactionIsAborted_WhenItReturns	fails, 236–244 of 300 still active in three runs	passes
RollbackAsync_DiscardsTheWrites_AndClearsCurrentTransaction	passes	passes
RollbackAsync_WithoutTransaction_IsANoOp	passes	passes
RollbackAsync_CalledTwice_RollsBackOnce	passes	passes

A test that a failing WAL abort write surfaces to the caller needs a fault-injection seam the storage engine does not have; Transaction.RollbackAsync already propagates the exception, and RollbackAsync is a plain forward of its ValueTask.

Full suite dotnet test tests/BLite.Tests (macOS, net10.0): 3097 passed, 0 failed, 4 skipped.

Fixes #307

🤖 Generated with Claude Code

[mrdevrobot]

Changes requested. Verified: Rollback() now completes before it returns; the load test fails on 0450b97 (264 of 300 transactions still Active) and passes here. The new RollbackAsync() is accepted for consistency with CommitAsync, but give it a CancellationToken parameter (default) on BLiteSession and on the generated session classes, as the other async entry points have. Then this can be merged after verification.

[CaffeinatedCoder]

Done in 22d66a1: BLiteSession.RollbackAsync and the generated session's RollbackAsync now take CancellationToken ct = default, like CommitAsync; the token is checked before the rollback starts, so a cancelled token throws and leaves the transaction active (new test RollbackAsync_CancelledToken_Throws_AndLeavesTheTransactionActive).