Repository navigation
fix: refuse null for a parameter the statement takes no null for - #75
Conversation
A parameter typed non-null bound NULL when the caller passed null or left it out, and the rows then broke the types the analysis gave them on that promise. The module now says which parameters take null, and the run time refuses null and a missing value for the others before the statement runs, a typed JSON parameter's included unless its schema allows null.
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
There was a problem hiding this comment.
Important
A JSON parameter with no schema is declared unknown in Params, so its type accepts null. With this change the run time throws on that same null, so code that type-checks now fails at run time.
Reviewed changes
I reviewed the emitted nullable flag, the new null refusal in statement(), and the docs and skill lines that describe it.
- Emitted
nullable:sqlModulewrites each parameter'snullablefrom the analysis intoinputs, so every build step's module carries it. - Run-time refusal:
statement()throws aParameterErrorfor a parameter withnullable: falsethat getsnullor is left out. A typed JSON parameter is refused only when its schema rejects null, and only after itsdefaulthas filled a missing value. Parameters typedunknownand hand-written queries without the flag are unchanged. - Docs and skill: the Inference page and
SKILL.mdnow say that any parameter withoutcoalescetakes no null. - Tests: there is a new test in
tests/execute.test.ts, and the module snapshots inanalyzeandcastsnow include"nullable":false.node --test tests/execute.test.tspasses locally (48/48).
claude-opus-5-5 | 𝕏
There was a problem hiding this comment.
✅ No new issues found. The new commits fix all three points from the last review.
Reviewed changes
I reviewed the two commits pushed since the last review: they bring the run-time null check in line with the declared Params types and correct the docs.
- Null check follows the declared type: the new
refusesNulllets null through for a parameter declaredunknown, which covers a parameter typedunknownand a JSON one with no schema. For a JSON parameter whose type has a schema of its own, it asks that schema whether null is allowed, and it refuses null for every other non-null parameter. This matchesrenderParamTypeinsrc/render.ts. checksimported when needed:sqlModulenow importschecksfor a non-null JSON parameter whose type has a schema, so the run time can check that schema.- Structured parameters keep their own message: the null check now runs after the
rowsbranch, sorow(…)androws(…)still say what to pass. - Docs and skill: the Inference page and
SKILL.mdnow say that a bare parameter written to a column that may hold null takes null too. - Tests: new cases cover a JSON parameter with no schema, a type schema that allows null, one that does not, and the structured-parameter message.
node --test tests/execute.test.tspasses locally (48/48).
claude-opus-5-5 | 𝕏

A parameter typed non-null bound NULL whenever the caller passed
nullor left it out, and the rows then broke their declared types: the engines infer a result's nullability on the promise that such a parameter holds a value.Any untyped input reaches this: a request body passed to
.run(), or a JavaScript caller.What changes
inputs[name].nullable)..run()and.runSync()refuse null, and a missing value, for a parameter whosenullableisfalse, withParameter "x" is null, and the statement takes no null for it: pass a value.(oris missing), before anything reaches the driver.defaultstill fills a missing value.unknown(strict_params: false) takes anything; and a query defined by hand withoutnullablebinds what it is given.