sqlite: fix crash on db.close() from inside a user function

[mceachen]

Calling db.close() from inside a user-defined function callback while sqlite3_step is on the call stack caused two distinct crashes:

1. DatabaseSync::Close ran sqlite3_finalize on the statement whose sqlite3_step frame was still active, freeing the VM that step was executing. The outer step then operated on freed memory.

2. Even if (1) is avoided, StatementExecutionHelper::Run dereferenced db->Connection() via sqlite3_last_insert_rowid / sqlite3_changes64 after step returned. The reentrant close zeroed connection_, so the deref crashed.

Add a MarkStepping() RAII guard wrapped around every sqlite3_step caller. If Finalize() is called while stepping_, defer it; the guard's destructor runs the deferred finalize after step returns. Add a connection-null check in StatementExecutionHelper::Run before the connection-dependent reads, throwing ERR_INVALID_STATE.

Fixes: #63180

(full disclosure: produced with assistance from claude and codex)

[nodejs-github-bot]

Review requested:

• @nodejs/sqlite

[codecov]

Codecov Report

❌ Patch coverage is 95.91837% with 2 lines in your changes missing coverage. Please review.
✅ Project coverage is 90.03%. Comparing base (bbf51ad) to head (c02e2c0).

Files with missing lines	Patch %	Lines
src/node_sqlite.cc	95.00%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #63183      +/-   ##
==========================================
- Coverage   90.03%   90.03%   -0.01%     
==========================================
  Files         713      713              
  Lines      224950   224986      +36     
  Branches    42532    42550      +18     
==========================================
+ Hits       202542   202572      +30     
- Misses      14175    14183       +8     
+ Partials     8233     8231       -2     

Files with missing lines	Coverage Δ
src/node_sqlite.h	83.09% <100.00%> (+2.45%)	⬆️
src/node_sqlite.cc	80.62% <95.00%> (+0.08%)	⬆️

... and 26 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Renegade334]

This definitely shouldn't segfault, but it's worth saying that "don't close the db handle during a user function callback" is expressly part of the sqlite3_create_function API contract, as is finalizing/resetting the statement, which I think we are also able to do:

let stmt;
db.function('x', () => stmt.get());
stmt = db.prepare('SELECT x()');
stmt.get();

Rather than performing forbidden operations and then mitigating against the consequences, it would probably be better to prevent those operations from occurring in the first place. Could we instead set some sort of state while a user callback function is being called, that causes attempts to close/finalize to be rejected with an exception?

[mceachen]

Thanks @Renegade334 -- agreed, switched to prevention.

DatabaseSync now tracks a user-callback depth via an RAII guard wrapped around every SQLite-invoked JS call (scalar xFunc, aggregate xStep/xValue/xFinal/xInverse/start, authorizer). While depth > 0, db.close(), the statement and tag-store execution methods, the iterator's next/return, tagStore.clear(), and db.deserialize() throw ERR_INVALID_STATE. Forbidden state is now unreachable, so the deferred-finalize machinery and the connection == nullptr check are gone.

New tests: aggregate step/result/start, authorizer, and reentrant iter.next() (your stmt.get()-from-callback example).

I just rebased to main (hence the force-push). Happy to squash before landing.

[mceachen]

Ugh, Derp, all nested statement execution from SQL functions is now rejected. I've added a regression test and will push a new diff soon.

Edit: the third commit is ready for review.