Skip to content
ttsulok

Library search works again for large libraries

For some large accounts, a search in Tatsulok failed every time it ran. The search now reads the library in pages and records where it stopped when it reaches a limit. This post covers what broke, what changed, and what is still bounded.

Updated

Warm off-white sheets covered in dense marks that cannot be read, with one small teal ink highlight in one corner

What broke on large libraries?

On one account that reported the problem, a single library search read 28,430 documents in one run. Convex, the database that runs our queries, caps the data one query or mutation execution can read at 16 MiB. The search went past that cap and failed. The measurement recorded in PR #9771, merged 2026-08-03, shows 8 of 8 runs failing, each between 4.0 and 5.6 seconds.

The failure was not random. The same work failed the same way every time, which is why it looked like an outage to anyone with a large library.

Why page the read instead of raising the limit?

The 16 MiB cap applies to each execution, and a search over a large library needs more than one. So the candidate list is now built across several executions. Each page is bounded by the bytes it reads, not by a row count, because a row count stops being a bound when rows grow. The rows here often hold whole documents.

One rule matters most. A page that Convex flags as possibly incomplete is never accepted as if it were complete. The search narrows the range and reads it again, or it records that the read was cut.

One search reads the library in pagesRead limitPages readWhere it stopped is declaredIt reads what it can. When it reaches a limit, it says so.

A second failure: too many entries in one answer

The same search also failed with a different error. A function may return at most 8,192 array entries, and one call tried to return 21,849 ids (reported in PR #9716, merged 2026-08-03). The fix packs ids into chunks of 250 per entry, so the cap counts chunks rather than individual documents. That raises the ceiling to about 2.05 million ids. A regression test uses the 21,849 count, so a change back to a bare array fails the suite.

What a search records now

When a search reads another person's shared library, the read is budgeted. When the budget is reached, the read stops and the search records that the scope was cut. It does not return a shorter list as if it were complete. On the exact-search path, the search tool tells the assistant when its scan did not cover the whole library, so the answer can say so.

FAQ

Why did library search fail for some accounts?
A search read more data in one execution than Convex allows, 16 MiB. Large libraries crossed that cap, and for those accounts the search failed on every run.
Does a search now read my whole library?
It reads in pages, so the size of one read no longer depends on the size of the library. A search can still stop early at a limit, and when it does, the cut is recorded rather than hidden. The shared-library list has a known cap of 250 notes per search, and that cut is not yet recorded.
What should I do if a search seems to miss a document?
Open the file yourself and find the sentence. A short result list is not proof that a document is missing, and it is not proof that the document exists either. Treat the search result as a starting point until you have read the source.
Did this change how citations work?
No. A citation still opens the exact passage in its source. This change affects which documents the search can consider before it answers.
Where can I check the limits behind this?
Convex publishes them in its documentation: 16 MiB of data read per query or mutation, and 8,192 elements per array. The page is linked in the sources below.

Sources

  1. Convex documentation: limits (16 MiB data read per query or mutation; 8,192 elements per array)

Related guides