[zahariash]

This work was produced with the help of language models.

Fixes #1377.

A COMMIT that failed with Buffer manager exception: Unable to allocate memory! The buffer pool is full and no memory could be freed! after its WAL commit record was durable was rolled back in memory, but a crash before the next checkpoint made recovery apply it. #1377's repro reopened with 187 nodes where the connection saw 186, and with the failed primary-key insert retried, reopening failed with Found duplicated primary key value 186, which violates the uniqueness constraint of the primary key column..

Fix.

• When applying a transaction fails after its COMMIT record is durable, TransactionManager::commit appends and syncs an ABORT record naming the offset of the transaction's records, then reports the original error.
• Recovery skips the named transactions in the active, frozen and graph WALs, so the failed COMMIT is not applied and the database stays writable. An ABORT naming no transaction committed after the last CHECKPOINT before it is ignored.
• If the ABORT cannot be written either, the WAL refuses writes until a reopen, which then applies the transaction, as the error says.
• A checkpoint waits for the rollback, so a COMMIT and its ABORT share a WAL file; WAL::logAbort refuses an offset outside the open file.
• The unused Transaction::commit(WAL*) is removed, and tools/wal_dump prints the new record.

Compatibility. Older builds read ABORT as a corrupt tail: they stop replay there and apply the transaction it undoes, or refuse to open with throwOnWalReplayFailure. The record lasts only until the next checkpoint retires the WAL; docs/checkpoint_recovery.md lists it with the other records older builds cannot read.

Tests. Three FailedCommitTest cases crash after a COMMIT fails while being applied, one with checksums off; main reopens with the failed relationship or node, or fails on the duplicated key. Others append an ABORT that names one of three transactions, sits in a frozen WAL, is torn, names nothing, or follows an unapplied CHECKPOINT, or make the ABORT or its sync fail. AbortRecordSkipsTheTransactionInAGraphWAL appends one to a graph's WAL from a standalone session, and FailedCommitLeavesOtherWritersCommits fails a commit between another writer's commits; each fails without its part of the fix. Full ctest: 3372/3372, with multi-writer mode as the default; storage-compat suite, every release: same results as main.

With #1378. main is merged in, so the aborted-block skip now runs in #1378's replay helper, which replays the active and the frozen WAL. AbortedCommitAfterPinnedCheckpointIsSkipped checks that an ABORT after a pinned checkpoint still keeps its transaction out. Without the skip in that helper, it and seven failed-commit tests fail. The recovery simulator passed on the merge, 40 workloads of 60 steps.

[adsharma]

ABORT-record approach looks right (sorted non-overlapping blocks, end-exclusive skip, torn-ABORT stands, unknown-ABORT ignored). Two correctness nits:

1. Cross-file ABORT: commit() drops the lock before logAbortOfDurableCommit, so a checkpoint could rotate WAL between COMMIT (frozen) and ABORT (active). dryReplay is per-file, so it would be ignored and the rolled-back txn re-applied. Consider holding the gate or collecting aborts globally.
2. blockStart = writer->getSize() must equal getReadOffset space (header/checksum). Tests pass but deserves a DASSERT/comment.

[zahariash]

Done in 8363d7fb8, 8c8d92b19 and e1263628b.

Cross-file ABORT. This can't happen, but nothing pinned it. After the failed publish, the transaction stays an active writer until the caller's rollback, which runs after logAbort has synced, and a checkpoint rotates or retires the WAL only once no writer is active. The lock commit() drops doesn't gate rotation, so the COMMIT and its ABORT always share a file, and I kept the per-file matching. WAL::logAbort now also refuses, in release builds too, an ABORT when no WAL file is open or its offset is at or past the file's end; the caller then poisons the WAL.

Offsets. Both are file offsets, with checksums on or off: no checksum entry is open between records, and dryReplay reads the BEGIN offset from the underlying BufferedFileReader. logCommittedWAL now asserts that the block grows the writer by exactly its own bytes, and FailedCommitIsNotAppliedAfterCrash also runs with checksums off.

Stray ABORT. The merge with #1378 turned up one more case. An ABORT naming no transaction still ended the WAL, so after a CHECKPOINT whose shadow wasn't applied yet it sent recovery down the prefix path, which fails on a duplicated key. The engine never writes that sequence, but an ABORT that names no transaction committed after the last CHECKPOINT is now ignored. StrayAbortRecordAfterCheckpointIsIgnored covers it.

[adsharma]

@zahariash - could you rerun the generate WAL script to fix sanity checks?

[zahariash]

Done: 936a10fee reruns the generator. The failure came from my earlier hand edit of the generated abort_record.cpp. 6bf0a5653 merges current main, and f3651dfd5 adds tests for an ABORT in a graph WAL and for a failed commit between another writer's commits. Ready for review.