fix(filter): accept runtime numeric values in filter_by#13
Merged
tharropoulos merged 1 commit intoMay 29, 2026
Merged
Conversation
Interpolating a `number` into a filter (e.g. `field:=${n}`) arrives as the
template-literal type `${number}`, which the tokenizer's char-split collapsed
into a single Head that doesn't extend NumericValue, falling through to
`Unknown token: ${number}`. Backtick-quoting type-checked but Typesense rejects
it at runtime ("invalid comparator"), so numeric fields had no working path for
runtime values.
Add a FilterTokenizer branch that treats a `${number}`/`${bigint}` placeholder
Head as a NumToken and recurses on the tail. Placed after the literal
NumericValue branch so literal digits keep their exact value, and the tail
recursion handles continuation clauses, arrays, and ranges.
Contributor
Author
|
thanks for the merge! lmk when you are able to cut a release as would love to be able to upgrade to the version with the fix! |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Interpolating a runtime
numberinto a filter fails to type-check:The value
humanReadableId:=1214009is valid at runtime, but there's currently no way to pass a runtime numeric value intofilter_by. The backtick escape that works for string fields (field:=`${value}`) doesn't help here — Typesense rejects a backtick-quoted number with "Numerical field has an invalid comparator". So the one form that type-checks is the one the engine refuses, and vice-versa.Cause
When a
numberis interpolated, the value arrives as the template-literal type`${number}`. The tokenizer's char-split (T extends \${infer Head}${infer Tail}`) collapses the whole placeholder intoHead, which doesn't extendNumericValue(Digit | "." | "-"), so it falls through toUnknown token: ${number}`. It's a coverage gap in the tokenizer.Fix
Add a
FilterTokenizerbranch that treats a`${number}`/`${bigint}`placeholder as aNumTokenand recurses on the tail. It's placed after the literalNumericValuebranch, so literal digits still go throughReadNumand keep their exact value (NumToken<"20">). The tail recursion handles continuation clauses, arrays, and ranges:humanReadableId:=${n}-> validhumanReadableId:=${n} && title:foo-> validhumanReadableId:[${n}]andhumanReadableId:[${a}..${b}]-> validInvalid filters are still rejected (wrong operator for a numeric field, unknown fields, etc.) — the fix isn't over-permissive.
Tests
Added tokenizer and
ParseFiltercases for${number}/${bigint}interpolation across:=, comparisons, arrays, ranges, and continuation clauses, plus a guard that literal numbers keep their exactNumTokenvalue.