feat: Migrate JS-sided locks to DatabaseQueue for transactions and executeBatch commands

[chrispader]

Changes the current JS lock implementation in favor of a DatabaseQueue, which is used for both transactions and batch executions

---

Note

Replace JS lock mechanism with a DatabaseQueue that serializes transactions and executeBatch operations, integrate it with session lifecycle, and update tests accordingly.

• Core:
  • DatabaseQueue: Add package/src/DatabaseQueue.ts with openDatabaseQueue/closeDatabaseQueue, queueOperationAsync, startOperationSync, and per-DB queue/inProgress tracking.
  • Transactions: Refactor transaction to run via DatabaseQueue, add finalized-state guards, wrap errors with NitroSQLiteError, support optional exclusive begin, and return generic Result.
  • Batch Ops: Route executeBatch/executeBatchAsync through DatabaseQueue; enforce throwIfDatabaseIsNotOpen.
  • Session Lifecycle: Wire open/close to openDatabaseQueue/closeDatabaseQueue; remove legacy lock usage.
  • API/Exports: Re-export NitroSQLiteError; update NitroSQLiteConnection.transaction signature to be generic and return the callback result.
• Tests:
  • Add example/src/tests/unit/specs/DatabaseQueue.spec.ts to verify queuing and error propagation for mixed operations.
  • Update unit tests to use isNitroSQLiteError, adjust paths, and rely on resetTestDb(); expose testDbQueue/TEST_DB_NAME for assertions.
  • Include ../package in example/tsconfig.json.

^{Written by Cursor Bugbot for commit 9bcae9c. This will update automatically on new commits. Configure here.}

[cursor]

Bug: Resource leak in database open error handling

Resource leak in error handling: If HybridNitroSQLite.open() succeeds but openDatabaseQueue() throws an error (e.g., if the database queue is already open), the native database will remain open while the database queue is not created. This leaves the system in an inconsistent state where the native database is open but the queue tracking doesn't exist. The code should either close the native database in the error handler, or call openDatabaseQueue() before opening the native database.

 

[chrispader]

This is true, but has been the behavior previously as well. I will address having multiple simultaneous database connections in a follow-up PR

[cursor]

Bug: Resource Leaks from Failed Close Blocking Reopen

Resource leak in error handling: If HybridNitroSQLite.close() throws an error, closeDatabaseQueue() is never called, leaving the database queue entry in the databaseQueues map. This prevents the database from being reopened later since openDatabaseQueue() will throw an error saying the database is already open. The code should ensure closeDatabaseQueue() is called even if closing the native database fails, possibly by reversing the order or using a try-finally pattern.

 

[chrispader]

Same here