2 commits

Author	SHA1	Message	Date
David Snelling	e766ed0a84	test(find-connected): close the brain this file leaks, and name the half a short answer came from ... TWO THINGS, both about the same file. THE LEAK, which is a defect of the test. `afterAll` set `brain = null`. That does not close a brain — it only makes it unreachable from here. The instance stayed open and registered with its unref'd cadence timer running, and the gate config runs the whole suite in ONE process (pool: 'forks', singleFork: true — two files report the same process.pid), so a brain leaked in this file goes on narrating its flushes into every file that runs after it. This one holds 151 entities and 30 relations. It is closed now. It is not the only leaker in the suite — a create-versus-close scan turns up 67 files with the same shape, and this is one of them, not the cause of anything on its own. Fixing the file I was already in. THE DIAGNOSTIC. 'walks the vector leg over the neighbours only' went red on the gate box (1 row of a requested 5) while passing here in isolation eight runs out of eight, beside its own box predecessor, and under a perturbed random stream — and it passed on the box one gate earlier behind the IDENTICAL predecessor. So the cause is process state accumulated by the time this file runs, and a bare count mismatch says nothing about which half broke. The case now runs the same query without the vector leg first, as a control, and reports both counts: both short means the neighbour set or the filter, only the vector leg short means the walk — which matters here because every row in this corpus carries an IDENTICAL vector, so the walk is ranking an exact tie and a tie has no defined order to return 5 of. The assertion is unchanged: still exactly 5, still every row a neighbour.	2026-09-02 16:14:24 -07:00
David Snelling	077cbc0b6f	fix(find): connected finds are graph-first — neighbours, then the filter over those ids, then the page ... With `connected` present, find() materialized the whole-store filtered id list, paged it, hydrated the page, and only then intersected with the neighbour set. Every such call paid O(store) for the filter and the hydration of rows that were never neighbours, and a neighbour outside the first page of the filtered STORE was silently dropped — the answer depended on the store's order and the page size. The neighbour set is now the candidate universe: resolved first from the adjacency, the metadata filter evaluated over those ids only through the provider's own evaluation (a new optional `filterIdsWithin` door on MetadataIndexProvider; the reference index implements it from its own getIdsForFilter so the two can never disagree; a provider without it is served by the whole-store answer intersected here), `orderBy` sorts the whole neighbour set before the page is cut, and the vector leg walks the neighbours as its candidate set. The text leg of a hybrid find keeps its post-intersection — it has no candidate door. Pinned in tests/integration/find-connected-order.test.ts: paging reaches every matching neighbour and never a non-neighbour; a `missing` negation is evaluated over the neighbours; the index is asked about the neighbour ids only and hydration is one page; orderBy sorts the whole set; the vector leg stays inside the neighbours; an edgeless anchor answers [] before the filter is asked.	2026-09-01 11:29:44 -07:00