A LangGraph SQLite filter can select the wrong large integer

A LangGraph SQLite store reproduction searches for integer 2^53 + 1 and receives the record for 2^53. Both values fit SQLite's signed integer range. If an application uses large sequence IDs or event numbers to retrieve agent memory, this is an identity error, not a cosmetic sort problem.

Diagnose the boundary

List the numeric fields used in store filters and their maximum values. Reproduce with two adjacent IDs around the boundary in a disposable SQLite store, then compare equality and ordered filters. The issue attributes the loss to float coercion of parameters and REAL casts in comparisons. SQLite's storage types distinguish INTEGER and REAL, which is why a numeric-looking filter can lose exactness. Confirm the package version; the issue tested current main declaring 3.1.3, not a separate PyPI installation.

Decide the next safe change

For an affected path, use exact string keys or another verified lookup strategy while the fix is pending, and assert that returned content belongs to the requested ID. Do not quietly round identifiers or infer that all SQLite reads are wrong. Add boundary tests with adjacent values and check asynchronous calls as well as synchronous ones. If memory controls a customer action, fail closed on an ID mismatch rather than feeding the agent a plausible but wrong record.

Evidence boundary

The report reproduces a wrong result on current main of checkpoint-sqlite 3.1.3; it does not claim a production incident or independent PyPI release test. The precision boundary is 2^53.

Adovo’s view

Memory is a trust boundary. A confident answer built on the neighboring customer's record is worse than a visible lookup failure. Keep identity exact from storage to response, especially when numbers cross precision boundaries.