sqlite: session[Symbol.dispose]() silently ignores the in-use guard

[arimxyer]

Version

v27.0.0-pre (current main)

Platform

Linux ari-cachyos 7.1.8-1-cachyos #1 SMP PREEMPT_DYNAMIC Mon, 10 Aug 2026 19:39:40 +0000 x86_64 GNU/Linux

Subsystem

node:sqlite

What steps will reproduce the bug?

const { DatabaseSync, constants } = require('node:sqlite');

for (const [name, close] of [
 ['close()', (session) => session.close()],
 ['[Symbol.dispose]()', (session) => session[Symbol.dispose]()],
]) {
 const db = new DatabaseSync(':memory:');
 db.exec('CREATE TABLE data(key INTEGER PRIMARY KEY, value TEXT)');
 const session = db.createSession({ table: 'data' });
 db.exec("INSERT INTO data VALUES (1, 'value')");

 let attempted = false;
 db.setAuthorizer(() => {
 if (!attempted) {
 attempted = true;
 try {
 close(session);
 console.log(`${name}: no throw`);
 } catch (error) {
 console.log(`${name}: ${error.code}: ${error.message}`);
 }
 }
 return constants.SQLITE_OK;
 });

 session.changeset();
 db.setAuthorizer(null);
 session.close();
 db.close();
}

How often does it reproduce? Is there a required condition?

Every time disposal is attempted while the session is generating a changeset or patchset.

What is the expected behavior? Why is that the expected behavior?

session[Symbol.dispose]() should throw the same ERR_INVALID_STATE as session.close() when the session cannot be closed safely. StatementSync already follows this pattern: its disposal propagates the active-statement guard, with coverage in test/parallel/test-sqlite-diagnostic-channel.js under “subscriber cannot close the database or statement”.

Expected output:

close(): ERR_INVALID_STATE: session is currently in use
[Symbol.dispose](): ERR_INVALID_STATE: session is currently in use

What do you see instead?

close(): ERR_INVALID_STATE: session is currently in use
[Symbol.dispose](): no throw

Session::Dispose() catches and discards the exception from Session::Close(). The session remains open even though disposal appeared to succeed.

Additional information

The reentrancy guard added by #65349 works: sqlite3session_delete() is not called while changeset generation is active, so this does not reproduce the use-after-free that the guard prevents. The remaining bug is the silent no-op and inconsistent error propagation from [Symbol.dispose]().