~ knotless Search/
↑↓ move↵ open⇧↵ all results

chadtmiller.com/knotless

git that lives in your Atmosphere account

knotless.dev
1 collaborator

knotless 0.13.0 Latest 2 packages, 1 image

1
10

A code search's pages go on from the one before

Merged
Merged chadtmiller.com asked to merge into main from chadtmiller.com/knotless:serve/search-ties

What changes

The second page of a code search no longer repeats a file from the first. Each page now asks Zoekt for the first 200 files, the deepest the pages go. It sorts files Zoekt scores alike by repository, then path, and answers its own slice.

Why

Zoekt has no cursor, and files it scores alike come back in whatever order its parallel shards answered. A page asked Zoekt for every file up to its own last and skipped those before. The first page could get one of two tied files and the second page the same one again, while the other was never shown. That is what searching_code caught now and then (web.rs, assert_ne!(next["files"][0]["repo"], first["files"][0]["repo"])): both pages showed needle-one. Two serve tests wait for the index and the code shards to settle fixed the test's shard-count waits, but not this.

Sorting alone wasn't enough. Zoekt cut the list at skip + limit before sorting, and it chose arbitrarily among the tied files at that cut. Asking for all 200 every time keeps every page cut from the same list, at the cost of more lines per query on the first pages.

How it was checked

searching_code's paging asserts now hold every time, rather than when the shards happen to answer in order. cargo clippy -p knotless-serve --lib --tests passes. The rest is left to CI.

Changeset: none

🤖 Generated with Claude Code

Approved

This makes every code-search page ask Zoekt for the same 200 files. It sorts them by score, then repository, then path, and slices out its own page. That gives every page the same total order, which fixes the repeated file in searching_code. I read all the changed files, AGENTS.md, and the surrounding search and search_code code, and found nothing that needs changing. I did not read the checks.

  • Tie at the cutoff: Zoekt's cut at MaxDocDisplayCount=200 can still pick arbitrarily among files tied exactly at rank 200. Only the last page's last few files could differ between requests, so this is acceptable. The design note could say it.
  • Docs: the api.md sentence "the best first, and those found alike by repository and path" reads awkwardly. Something like "files scored alike ordered by repository, then path" would be clearer.
  • Cost: the first page now fetches 200 chunk-matched files every time. You already say that in the body and docs.
Approved

Carried forward: the change this pull makes at 5387c29bc5cf1027b9c25b549f3505742b2f2344 is the one reviewed at b8c78063e805c266160cf5cf51c5affba84c0914, so that review stands. What is new comes from its base.

Merged as 45bb659