pub const NO_LIMIT_RESULT_MIN: usize = 1_000;Expand description
Upper bound on how many documents a limit == 0 (“no limit”) search is
allowed to materialize. Each SearchHit carries the full message
content string (roughly 80 KB p99 in real corpora), so an unlimited
search on a ~500k-row user history can easily allocate tens of
gigabytes of heap AND drive sustained multi-GB/s reads off the Tantivy
.store file and SQLite rows, crushing the whole machine.
The cap is computed dynamically from /proc/meminfo MemAvailable
(Linux) so a dev box with 512 GB of RAM is allowed to return ~200k
rows while a 2 GB laptop stops at the floor. The cap translates
directly into an upper bound on disk-I/O per query because the
per-hit hydration loop in fs_load_doc() / hydrate_tantivy_hit_contents
does ~11 .store field reads per hit plus up to one SQLite row
fetch — bounding hits bounds bytes read.
Override with CASS_SEARCH_NO_LIMIT_CAP=<hits> or
CASS_SEARCH_NO_LIMIT_BYTES=<bytes>. Both overrides are still
clamped to [NO_LIMIT_RESULT_MIN, NO_LIMIT_RESULT_MAX] on the way
out — an unclamped override would re-open the same “crush the
machine” hole this cap exists to close.