fix(lib): cap what a search collects

Counting cheaply was not enough: on the live network peers answer a popular query for minutes after the window closes, and nothing ever stopped the pile-up. One 'aphex twin' search grew to 867,990 files and 2.1 GB of daemon memory, and a single search.results reply serialized 134 MB of JSON over 104 seconds - an attached TUI that touched the search froze for minutes, which read as the whole application being forever slow. A search now stops collecting at 500 responses or 10,000 files, whichever comes first, the same shortlist stance other clients take: a result set is something to pick from, not an archive of everyone who answered. The same search now plateaus at ~10k files, a 1.55 MB reply in 23 ms, and 231 MB of daemon memory; the attached TUI idles at zero CPU with the search open.
2026-08-09 22:49:56 +02:00
parent 1551fbbf1b
commit 6eaf33fbaa
3 changed files with 81 additions and 18 deletions
@@ -44,7 +44,7 @@ impl Client {
                        // Find the search with matching token
                        for search in context.searches.values_mut() {
                            if search.token == result_token {
-                                search.results.push(search_result);
+                                search.accept(search_result);
                                break;
                            }
                        }