sqlite: run() throws after committing when lastInsertRowid exceeds 2^53

[araujogui]

Version

v27.0.0-pre (main @ 4486dce)

Platform

Darwin 25.6.0 arm64

Subsystem

sqlite

What steps will reproduce the bug?

const { DatabaseSync } = require('node:sqlite');
const db = new DatabaseSync(':memory:');
db.exec('CREATE TABLE r(id INTEGER PRIMARY KEY); CREATE TABLE o(x)');
db.prepare('INSERT INTO r VALUES (?)').run(2n ** 53n + 1n); // ERR_OUT_OF_RANGE, row is inserted
db.prepare('DELETE FROM o').run();                          // ERR_OUT_OF_RANGE

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

Always, when readBigInts is off and the connection's last insert rowid exceeds 2^53.

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

run() shouldn't throw after the write has committed. Proposal: return a BigInt for out-of-range values regardless of readBigInts. Is that acceptable, or should we only document it?

What do you see instead?

run() converts lastInsertRowid and changes only after stepping (src/node_sqlite.cc:4153). If a value is outside the safe-integer range, it throws, but the write has already committed. The last insert rowid belongs to the connection, so every later run() on that connection also throws. Not documented.

Additional information

No response

[this-caroline]

I reproduced this and have a local patch using the proposed BigInt fallback for run() metadata.

With BigInt reads disabled, safe values remain numbers and out-of-range values return BigInts
I added tests for large row IDs, subsequent deletes, and positive/negative boundaries.

This changes the existing expectation that large lastInsertRowid values throw.
Would this approach be acceptable?

Happy to open a PR

[Renegade334]

Proposal: return a BigInt for out-of-range values regardless of readBigInts. Is that acceptable, or should we only document it?

-1 to changing the meaning of this option to "return number except when the API decides that isn't actually what you wanted".

I kinda think the existing behaviour is fine, so long as the error is descriptive. Anyone even remotely likely to be working with 2^53-sized tables should absolutely have bigints enabled, and we're not leaving the table in any kind of invalid or unrecoverable state.

[this-caroline]

Fair point
A single explicitly assigned large row ID is enough to trigger this, it doesnt require a large table, because lastInsertRowid is connection-level state, subsequent updates/deletes can also throw after the write has already taken effect

Would a documentation-and-test PR be welcome?
I’d clarify that metadata conversion can throw after execution, that the exception doesn’t itself roll back the write, and that BigInt reads should be enabled on affected statements