GAUNTLET (Titan phase 15 audit, rule 16) flagged that closeDbPair, closeDbPairDeferred, and closeDbDeferred have zero direct test coverage in tests/, despite being core resource-lifecycle primitives in src/db/connection.ts — a fanIn-55 file. This is exactly the kind of gap where the phase-15 resource-leak bug (openReadonlyWithNative opening the DB handle before config resolution, which could throw and leak it — see the phase-15 commit) went undetected for a long time.
Phase 15 added direct regression coverage for openReadonlyWithNative specifically (tests/unit/openReadonlyWithNative-leak.test.ts), but did not extend coverage to closeDbPair, closeDbPairDeferred, or closeDbDeferred — out of scope for that narrowly-defined commit (per sync.json's phase-15 label).
Recommendation: add direct unit tests exercising:
closeDbPair: both handles close in the right order (native first, then better-sqlite3); native close failure doesn't prevent the better-sqlite3 close.closeDbPairDeferred: native closes immediately, better-sqlite3 close is deferred via closeDbDeferred.closeDbDeferred: the advisory lock releases immediately; the handle actually closes on the next tick; flushDeferredClose() closes it synchronously before that tick if called first.
GAUNTLET (Titan phase 15 audit, rule 16) flagged that
closeDbPair,closeDbPairDeferred, andcloseDbDeferredhave zero direct test coverage intests/, despite being core resource-lifecycle primitives insrc/db/connection.ts— a fanIn-55 file. This is exactly the kind of gap where the phase-15 resource-leak bug (openReadonlyWithNative opening the DB handle before config resolution, which could throw and leak it — see the phase-15 commit) went undetected for a long time.Phase 15 added direct regression coverage for
openReadonlyWithNativespecifically (tests/unit/openReadonlyWithNative-leak.test.ts), but did not extend coverage tocloseDbPair,closeDbPairDeferred, orcloseDbDeferred— out of scope for that narrowly-defined commit (per sync.json's phase-15 label).Recommendation: add direct unit tests exercising:
closeDbPair: both handles close in the right order (native first, then better-sqlite3); native close failure doesn't prevent the better-sqlite3 close.closeDbPairDeferred: native closes immediately, better-sqlite3 close is deferred viacloseDbDeferred.closeDbDeferred: the advisory lock releases immediately; the handle actually closes on the next tick;flushDeferredClose()closes it synchronously before that tick if called first.