Filtering Nested Array Objects Hangs Indefinitely in v29

[rajaie]

Bug Description

I recently upgraded from v27.1 to v29 and tried to use the new nested array object filtering syntax.

I had a filterBy query that looked like this

id:!=[6536380] && ((remote_locations:US) || (locations.country:=US && locations.stateOrProvince:=CO && locations.city:=Denver) ) && employer_id:!=[16832] && posting_date:[1746506569..1754282569] && salary_ending_range:>=70000

which returned pretty quickly (<200ms)

and now this filterBy just hangs indefinitely

id:!=[6536380] && ((locations.{country:=US && stateOrProvince:=CO && city:=Denver}) || (remote_locations:US)) && employer_id:!=[16832] && posting_date:[1746506764..1754282764] && salary_ending_range:>=70000

If I get rid of && city:=Denver from my query using the new filter syntax, I get a response but it takes about 6 seconds.

If I remove && stateOrProvince:=CO && city:=Denver, I get a response in about 300 ms.

So the new filtering syntax is working, it just seems to be super super slow. Is that expected, or is there something going on? I can share more info but it just seems there's something that isn't right.

Reproduction Steps

The example at https://typesense.org/docs/guide/tips-for-filtering.html#filtering-nested-array-objects is good enough, you should be able to reproduce it using that but with a lot more records

Expected vs Actual

Expected behavior
To get a response

Actual behavior
Response times out

Environment

• Typesense version: I'm using the latest 29 Docker image
• Operating system: Ubuntu 22.04.5 x86_64

Additional Context

I have ~1 million documents in this collection

[alangmartini]

@rajaie ,

Whenever you add a &&, you are exponentially increasing the processing needed.

It will also depend hugely on the number of documents you are searching for. Could you try using the enable_lazy_filter parameter?

Could you provide a minimal reproducible example using the script below?

https://gist.github.com/jasonbosco/7c3432713216c378472f13e72246f46b

[rajaie]

There are about 1 million documents in my collection, so not a lot. I will try enable that setting and see if it makes a difference. Are there any downsides to setting it to true?

…

On Tue, Aug 5, 2025 at 11:23 AM Alan Galvao ***@***.***> wrote: *alangmartini* left a comment (typesense/typesense#2469) <#2469 (comment)> @rajaie <https://github.com/rajaie> , This is expected since whenever you add a &&, you are exponentially increasing the processing needed. It will also depend hugely on the number of documents you are searching for. Could you try using the enable_lazy_filter parameter? — Reply to this email directly, view it on GitHub <#2469 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADQ7F67CTPKXJUEMOLECBY33MDEA3AVCNFSM6AAAAACDA57J4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTCNJVGY3DKMZYGA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[happy-san]

@rajaie I believe it's related to the size of the document since we load the entire document while filtering on nested array objects.

[jh-revers]

Hi, same problem here with some queries taking minutes instead of seconds.
I tried enable_lazy_filter but without change.

Is there a workaround or a recommendation to avoid nested arrays ?

@rajaie do you still have this issue ?

[rajaie]

I ended up sticking to 27.1 since I didn't have the time to try upgrading again and enabling that setting

…

On Thu, Oct 23, 2025 at 4:48 AM jh-revers ***@***.***> wrote: *jh-revers* left a comment (typesense/typesense#2469) <#2469 (comment)> Hi, same problem here with some queries taking minutes instead of seconds. I tried enable_lazy_filter but without change. Is there a workaround or a recommendation to avoid nested arrays ? @rajaie <https://github.com/rajaie> do you still have this issue ? — Reply to this email directly, view it on GitHub <#2469 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADQ7F63DZMRCK5X25YJ6BG33ZCI4TAVCNFSM6AAAAACDA57J4GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIMZVG44TGNBUHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[fogx]

parent.{a && b} is the only correct way to require one array element to satisfy both conditions, the flat && form pairs across elements. It is unusable past small collections. Would be great if we could have a fix for this!

With 50,000 docs, indexing readings as an object array of 1 to 4 {sensor, level}. readings.sensor faceted string[], readings.level int32[] with range_index. One extra float[] field, in no filter, sized to vary the stored document. On typesense/typesense:31.0.rc12.

9,693 matches out of the 11,617 docs containing s02:

bytes/doc	readings.{sensor:=s02 && level:>=20}
428 B	366 ms
3.9 kB	1,400 ms
15.3 kB	4,544 ms

Either condition alone is fast at every size, readings.sensor:=s02 5.5 to 28 ms and readings.level:>=20 9 to 28 ms while matching 47,540 docs. Only the same-object form is slow, and it scales with candidates as well as document size: readings.{sensor:=s01 && level:>=20} is 6,087 ms at 15.3 kB.

That lines up with @happy-san, the entire document gets loaded. In src/filter_result_iterator.cpp, validate_object_filter does a get_document_from_store and a full nlohmann::json::parse per candidate, plus field::flatten_doc since flat keys are stripped before persisting.

• enable_lazy_filter does not help. init() compares min(left, right) against COMPUTE_FILTER_ITERATOR_THRESHOLD (25,000) and calls compute_iterators() below it, which materialises the whole intersection and validates every candidate up front. So per_page makes no difference to how many documents get parsed.
• Fix same object filtering with on array[] #2899 is not relevant.

The fix might be fairly straight forward? The string side already records which element matched, Index::tokenize_string_array pushes the array index into the token offsets. The numeric side drops it: num_tree_t is a map of id lists, NumericTrie::Node carries only seq_ids. If the numeric index kept element position too, could this resolve as an index intersection and never touch the document store.

Reproduction script (docker + stdlib python3)

#!/usr/bin/env python3
"""
Minimal reproduction for typesense/typesense#2469: same-object array filters
(`parent.{a && b}`) scale with stored document size and candidate count.

Requires: docker, python3 (stdlib only).
Run:      python3 mre_2469.py

What it does:
  1. Starts typesense 31.0.rc12 in a container.
  2. Builds three pairs of collections holding IDENTICAL data, differing only in
     the stored size of one irrelevant float[] field (32, 384, 1536 dims), and in
     whether that field is `store: false`.
  3. Times `readings.{sensor:=s02 && level:>=20}` on each.

Expected: latency grows with stored document size when the field is stored, and
is flat when it is not, even though the field appears in no filter and the result
counts are identical.
"""
import json
import random
import statistics
import subprocess
import time
import urllib.error
import urllib.parse
import urllib.request

BASE = "http://localhost:8108"
KEY = "mre-2469-throwaway-key"
IMAGE = "typesense/typesense:31.0.rc12"
DOCS = 50_000
BLOB_DIMS = [32, 384, 1536]
REPS = 6  # first discarded as cold

# s01 lands in ~50% of documents, s02 in ~3%. Levels are always >= 5.
SENSORS = ["s01", "s02", "s03", "s04", "s05", "s06", "s07", "s08", "s09", "s10"]


def call(method, path, body=None, timeout=600, raw=False):
    data = body if isinstance(body, bytes) else (json.dumps(body).encode() if body else None)
    req = urllib.request.Request(f"{BASE}{path}", data=data, method=method)
    req.add_header("X-TYPESENSE-API-KEY", KEY)
    req.add_header("Content-Type", "application/json")
    try:
        with urllib.request.urlopen(req, timeout=timeout) as r:
            payload = r.read()
    except urllib.error.HTTPError as e:
        raise SystemExit(f"{method} {path} -> {e.code}: {e.read().decode()[:400]}")
    if raw:  # /documents/import answers with JSONL, one result per line
        return payload
    return json.loads(payload) if payload else None


def start_container():
    subprocess.run(["docker", "rm", "-f", "ts-mre"], capture_output=True)
    subprocess.run(["docker", "volume", "rm", "-f", "ts-mre-data"], capture_output=True)
    subprocess.run(["docker", "volume", "create", "ts-mre-data"], capture_output=True)
    subprocess.run(
        ["docker", "run", "-d", "--name", "ts-mre", "-p", "8108:8108",
         "-v", "ts-mre-data:/data", IMAGE,
         "--data-dir", "/data", "--api-key", KEY],
        capture_output=True, check=True,
    )
    for _ in range(120):
        try:
            if call("GET", "/health").get("ok"):
                return
        except (Exception, SystemExit):
            pass  # 503 while the data dir is still being opened
        time.sleep(1)
    raise SystemExit("container never became healthy")


def schema(name, dims, store_blob):
    blob = {"name": "blob", "type": "float[]", "optional": True}
    if not store_blob:
        blob["store"] = False
    return {
        "name": name,
        "fields": [
            {"name": "id", "type": "string"},
            {"name": "name", "type": "string"},
            {"name": "readings.sensor", "type": "string[]", "facet": True, "optional": True},
            {"name": "readings.level", "type": "int32[]", "optional": True,
             "range_index": True},
            blob,
        ],
        "enable_nested_fields": True,
    }


def build_corpus(dims, seed=1):
    """Identical readings data for every dims value; only the blob length varies."""
    rng = random.Random(seed)          # same stream every time -> same readings data
    blob_rng = random.Random(seed + 999)
    rows = []
    for i in range(DOCS):
        n = rng.choice([1, 2, 3, 4])
        ids = rng.sample(SENSORS, n)
        if rng.random() < 0.50 and "s01" not in ids:
            ids[0] = "s01"
        if rng.random() < 0.03 and "s02" not in ids:
            ids[-1] = "s02"
        values = [rng.randint(5, 95) for _ in ids]
        rows.append(json.dumps({
            "id": str(i),
            "name": f"doc {i}",
            "readings": [{"sensor": c, "level": v} for c, v in zip(ids, values)],
            "blob": [round(blob_rng.random(), 6) for _ in range(dims)],
        }))
    return rows


def load(name, rows):
    call("POST", f"/collections/{name}/documents/import?action=create",
         body=("\n".join(rows)).encode(), timeout=1800, raw=True)
    return call("GET", f"/collections/{name}")["num_documents"]


def timed(name, filter_by):
    qs = urllib.parse.urlencode({
        "q": "*", "query_by": "name", "filter_by": filter_by,
        "per_page": "1", "include_fields": "id", "exclude_fields": "blob",
    })
    times, found = [], None
    for i in range(REPS):
        t0 = time.perf_counter()
        body = call("GET", f"/collections/{name}/documents/search?{qs}", timeout=120)
        if i:
            times.append((time.perf_counter() - t0) * 1000)
        found = body.get("found")
    return round(statistics.median(times), 1), found


FILTERS = [
    ("same-object   s02 >=20", "readings.{sensor:=s02 && level:>=20}"),
    ("same-object   s01 >=20", "readings.{sensor:=s01 && level:>=20}"),
    ("single cond   sensor=s02", "readings.sensor:=s02"),
    ("single cond   level>=20", "readings.level:>=20"),
]

start_container()
print(f"typesense {call('GET', '/debug')['version']}, {DOCS} docs per collection\n")

for dims in BLOB_DIMS:
    rows = build_corpus(dims)
    approx = len(rows[0])
    for store_blob in (True, False):
        name = f"c{dims}_{'stored' if store_blob else 'unstored'}"
        try:
            call("DELETE", f"/collections/{name}")
        except SystemExit:
            pass
        call("POST", "/collections", schema(name, dims, store_blob))
        load(name, rows)
        label = "stored" if store_blob else "store:false"
        line = [f"blob {dims:5} dims (~{approx} B/doc source)  {label:11}"]
        for desc, f in FILTERS:
            ms, found = timed(name, f)
            line.append(f"{desc} {ms:8.1f}ms n={found}")
        print("  ".join(line), flush=True)
    print()

print("teardown: docker rm -f ts-mre")

[ddeboer]

This is a real defect rather than the cost of &&, and it is already fixed – neither of which is visible from this thread, so it seems worth recording.

Bisected. 31.0.rc1 hangs; 31.0.rc5, rc10 and rc14 all answer correctly and in milliseconds. So it was fixed somewhere in rc2–rc5. It still reproduces on 30.2, the current stable release.

It is a hang, not a slow scan. At 1 000 000 documents the welded filter never returns – no error, no timeout, no response – while either condition alone answers in 16 ms over the same data. CPU stays flat and other queries keep being served, so it is not work in progress.

One document reproduces it, which rules out collection size:

filter_by=credit.{role:=etser && agent_id:=p1}

  stored as role:["etser"] agent_id:["p1"]   → no response, ever
  stored as role:"etser"   agent_id:"p1"     → 1 hit, 5 ms

Same schema, same filter, same values – only the stored value shape differs.

The trigger is narrower than “nested array filtering”. Both conditions must find a match somewhere in the document and at least one matched value must be array-valued. Specifically:

• a document matching neither condition is never slow, however array-shaped;
• a single array-valued leaf on either side is enough – role:"etser" agent_id:["p1"] hangs exactly as hard as both-arrays;
• it is not specific to numeric fields (cf. filter_by hangs indefinitely combining a range condition with an equality condition on two numeric fields inside a nested object[] {...} block (2+ array elements) #2964, which is very likely the same defect) – two string[] equality conditions reproduce it;
• one condition inside the braces, or the same two conditions written outside them, always answer instantly.

That last point is probably why the documented example never showed it: ingredients.{name:=cheese && concentration:<50} holds scalars in each object.

Given the fix is in the 31.0 release candidates, the useful thing here may be a note that 30.2 users need to store single values in the leaves a {...} filter names – which is the workaround we shipped, and it costs nothing once 31.0 lands.