fix(inputlayer-js): refuse NaN, infinities and out-of-range integers instead of emitting them as IQL variables - #251

✅ No issues found.

✅ No issues found.

• ⚠️ packages/inputlayer-js/src/relation.ts:184 - The new 64-bit range check also rejects valid floats. JS cannot tell an int from a float whose value happens to be whole, and every double at or above 2^63 in magnitude is a whole number. So values like 1e19, 1e20, 1.5e19 and 1e300 in a float column or a vector are now refused with CompileError. Before this change they were sent as digits or as 1e+21, which the engine parses as f64 (src/parser/mod.rs:361-369: it tries i64 and falls back to f64), so they round-tripped correctly. Python keeps accepting them, because _encode_float/_encode_vector_item emit repr(float), so this breaks the Python parity the intent asks for in the float/vector case. Example: kg.insert(Scored, {order:1, tool:'t', score:1e20}) used to work and now throws. The new test even asserts compileValue(1e300) throws. Fix options: use the column type where it is known (fact compilation has columnTypes) and refuse out-of-range values only for int columns, or emit an integral value past the range as a float literal. Vector items should always be encoded as floats, as in Python. This is ask-user because choosing the type rule for type-blind compileValue callers is a policy decision.
• ⚠️ packages/inputlayer-js/src/knowledge-graph.ts:407 - claim() runs compileValue on rows the engine sends back, in rows.some(r => r.every(v => compileValue(v) === ours[i])), after the claim program has already committed. compileValue can now throw on those values. An i64 such as 9223372036854775807 is JSON-decoded to the number 2^63, and a holder row can hold a float ≥2^63 (for example one written by the Python SDK). Either one makes claim() throw CompileError, even though the write went through, so the caller cannot tell whether it won. Before this change the comparison just failed to match. Fix: compare engine values without throwing, for example by wrapping the call in a try/catch that counts as no match, or with a non-throwing comparison helper.
• ⚠️ packages/inputlayer-js/src/knowledge-graph.ts:804 - whyNot() has its own literal encoder that bypasses compileValue: it uses String(v) for non-strings. So kg.whyNot(Scored, {order: 1, tool: 't', score: NaN}) still sends a bare NaN/Infinity token, which the parser reads as a variable. The query then explains a pattern instead of the fact, with no error. The new test says NaN is refused on 'every write and query path', but this read path is missed. It cannot lose data, but it returns a wrong result silently. Fix: encode each value with compileValue (this also brings in the full string escaping).
• ℹ️ packages/inputlayer-js/src/relation.ts:183 - The intent asks the JS encoder to refuse 'non-finite and unsafe numbers like _literal.py'. The change reads 'unsafe' as 'outside signed 64-bit', which matches Python. But integers above Number.MAX_SAFE_INTEGER (2^53) and below 2^63 are still accepted, even though they may already have been rounded before reaching the SDK. For example, a retract keyed on 9007199254740993 actually targets ...992. Please confirm that the i64 range is the intended meaning of 'unsafe', not Number.isSafeInteger.

🔧 Fix applied.
4 warnings still open:

• ⚠️ packages/inputlayer-js/src/knowledge-graph.ts:407 - claim() runs compileValue on rows the engine sends back, in rows.some(r => r.every(v => compileValue(v) === ours[i])), after the claim program has already committed. compileValue can now throw on those values. An i64 such as 9223372036854775807 is JSON-decoded to the number 2^63, and a holder row can hold a float ≥2^63 (for example one written by the Python SDK). Either one makes claim() throw CompileError, even though the write went through, so the caller cannot tell whether it won. Before this change the comparison just failed to match. Fix: compare engine values without throwing, for example by wrapping the call in a try/catch that counts as no match, or with a non-throwing comparison helper.
• ⚠️ packages/inputlayer-js/src/knowledge-graph.ts:804 - whyNot() has its own literal encoder that bypasses compileValue: it uses String(v) for non-strings. So kg.whyNot(Scored, {order: 1, tool: 't', score: NaN}) still sends a bare NaN/Infinity token, which the parser reads as a variable. The query then explains a pattern instead of the fact, with no error. The new test says NaN is refused on 'every write and query path', but this read path is missed. It cannot lose data, but it returns a wrong result silently. Fix: encode each value with compileValue (this also brings in the full string escaping).
• ⚠️ packages/inputlayer-js/src/knowledge-graph.ts:408 - The round-1 fix for F2/F4 made claim() report a false loss when the row holds a BigInt past 2^53. Round 1 started accepting BigInt in int columns, so ours holds exact digits, for example "9007199254740993". The engine reply is decoded with plain JSON.parse (protocol.ts:374), which rounds that i64 to the number 9007199254740992. In the new non-throwing same, compileValue(9007199254740992, 'int') then throws because the value is past MAX_SAFE_INTEGER. The catch turns that into false. Concrete case: kg.claim(Rel, {id: 9007199254740993n, ...}, {key:['id']}) commits and the engine returns our own row, yet claim() returns {won:false, holder:<our row with id rounded>}. The caller is told it lost a claim it actually holds, and nothing errors. Before this change BigInt was refused outright, so this wrong-result path is new. No other compare site uses engine rows. Remedy options: refuse a BigInt outside the safe range up front in claim(), or decode engine integers losslessly. The second extends the protocol layer, so the remedy choice needs authorization.
• ⚠️ packages/inputlayer-js/src/compiler.ts:154 - The round-1 fix (F1/F4) left the comparison-literal path behind and changed what it sends. compileExpr compiles a Literal with compileValue(expr.value) and no column type. A whole number past 2^53 in an int-column filter now goes out as a float literal: Rel.col('id').eq(2**60) becomes 1.152921504606847e+18, where it used to be the exact 1152921504606846976. The user decision says such a number in an int position must be refused with a CompileError asking for a BigInt. Here it is neither refused nor sent as an int. The engine's equality does not treat Int64 and Float64 as equal (src/provenance/unification.rs:225 values_equal). So kg.query({where: Rel.col('id').eq(2**60)}) silently returns nothing, and kg.delete(Rel, Rel.col('id').eq(2**60)) silently deletes nothing, where both used to match. Other sites that compile a literal without its type: compiler.ts:186 (aggregate params), and compiler.ts:491/501, which compare an untyped encoding against a typed one. Remedy: resolve the column's type for Column-vs-Literal comparisons and pass it to compileValue, or define a policy for when the type is unknown (for example, keep integral values within i64 as digits). The user decision only covered cases where the type is known, so the unknown-type policy needs confirmation.

🔧 Fix applied.
2 issues (1 warning, 1 info) still open:

• ⚠️ packages/inputlayer-js/src/protocol.ts:387 - Round 2 (the R2-1 fix) added lossless integer decoding. It is meant to switch to the slow reviver path only when a frame holds a large integer, but the gate /\d{16}/.test(data) also matches the 16–17 significant digits that serde/ryu writes for ordinary floats (e.g. 0.30000000000000004, or any random score). So almost every result, subscription snapshot or delta frame with a float column now goes through JSON.parse with a reviver. I measured a 50k-row [int, string, float] frame on Node 22: 14 ms plain versus 112 ms with the reviver, about 8x slower. This sits on the hot path for every query and subscription delta (see issue Pipelined standing-query evaluations: bring 100-session write→delta p99 under 100 ms #238 on the p99 write→delta latency target). Fix: tighten the gate so it matches only a standalone integer token of 16 or more digits, i.e. not inside a fraction or exponent. One option: /(?:^|[^\d.eE+-])-?\d{16,}(?![\d.eE])/. A false positive inside a string literal only costs speed, not correctness.
• ℹ️ packages/inputlayer-js/src/protocol.ts:375 - The lossless decoding relies on the reviver's third context.source argument (JSON.parse source text access). Node 22 (used in CI) has it. On runtimes without it the reviver gets no context, so it silently falls back to lossy numbers. The package declares no engines field. On those runtimes the R2-1 false-loss path in claim() (a BigInt key past 2^53 reported as {won:false}) can still happen. Consider declaring engines: {node: '>=22'} or noting the requirement.

🔧 Fix applied.
1 info still open:

• ℹ️ packages/inputlayer-js/src/protocol.ts:375 - The lossless decoding relies on the reviver's third context.source argument (JSON.parse source text access). Node 22 (used in CI) has it. On runtimes without it the reviver gets no context, so it silently falls back to lossy numbers. The package declares no engines field. On those runtimes the R2-1 false-loss path in claim() (a BigInt key past 2^53 reported as {won:false}) can still happen. Consider declaring engines: {node: '>=22'} or noting the requirement.

✅ No issues found.

• Live validation: ✅ go - 8 of 8 scenarios driven live against the product

• cargo build --release --bin inputlayer-server, then started a disposable server on 127.0.0.1:8097 with a temp --data-dir
• Built the SDK at both the base commit (c649d122) and the target commit (4e17440c) with tsup, and ran the same live scenario script (node scenarios.mjs base|after) against the server
• npx vitest run tests/guards.test.ts tests/relation.test.ts tests/protocol.test.ts
• INPUTLAYER_TEST_SERVER=ws://127.0.0.1:8097/ws npx vitest run tests/guards.integration.test.ts

✅ No issues found.

✅ No issues found.

✅ No issues found.