fix(lbug): keep conn.close()/db.close() literals out of the closeLbug comment (#2264 review P1-1)

The skipNativeClose comment in closeLbug contained the literal `conn.close()`/
`db.close()`, which the structural guard test (lbug-checkpoint.test.ts:52-53 —
"closeLbug must not inline conn.close()/db.close()") greps for and fails on.
Reword the comment to describe the native close without the literal tokens; the
code already delegates close exclusively to safeClose, so the guard's intent holds.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JBJomjoTdBV2eveDVq4JMm
This commit is contained in:
Gergo Magyar 2026-06-21 07:41:26 +00:00
parent a84645a4b1
commit 8589feb518

View file

@ -1902,18 +1902,21 @@ export const safeClose = async (): Promise<void> => {
export const closeLbug = async (options: { skipNativeClose?: boolean } = {}): Promise<void> => {
if (options.skipNativeClose) {
// The caller is about to exit the process (CLI analyze success/error/SIGINT
// all end in process.exit). CHECKPOINT for durability, then DELIBERATELY skip
// conn.close()/db.close(): LadybugDB's ClientContext/Connection destructor can
// double-free after large --pdg writes (gdb: `double free or corruption` in
// ClientContext::~ClientContext via NodeConnection::Close), aborting the
// process AFTER a fully-written, checkpointed index. flushWAL above already
// persisted the data; process exit reclaims the native handles. We leave
// conn/db referenced and module state intact so a GC finalizer cannot run the
// same destructor before exit, and any post-analyze read reuses the live
// connection. Mirrors the pool adapter's fire-and-forget native close
// (pool-adapter.ts) and the ONNX native-cleanup philosophy. This is a
// workaround for a LadybugDB engine bug — see the upstream report.
// The caller guarantees a process.exit afterward (CLI analyze success path).
// CHECKPOINT for durability via flushWAL, then DELIBERATELY skip the native
// connection and database teardown: LadybugDB's ClientContext/Connection
// destructor can double-free after large --pdg writes (gdb: `double free or
// corruption` in ClientContext::~ClientContext via NodeConnection::Close),
// aborting the process AFTER a fully-written, checkpointed index. flushWAL
// already persisted the data; process exit reclaims the native handles. We
// leave the handles referenced and module state intact so a GC finalizer
// cannot run the same destructor before exit, and any post-analyze read
// reuses the live connection. Mirrors the pool adapter's fire-and-forget
// native teardown (pool-adapter.ts) and the ONNX native-cleanup philosophy.
// Workaround for a LadybugDB engine bug (to be reported upstream).
// SAFETY: only valid when a process.exit is guaranteed to follow — the
// runFullAnalysis ERROR path intentionally does NOT pass this (it closes for
// real, so a soft-returning caller still releases handles and terminates).
await flushWAL();
return;
}