[bug] Search result hydration performs duplicate repository lookups within the same chunk
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 84/100
- Issue type
- Bug
- Clarity
- Clearly specified
- Activity status
- Active
- Tech stack
- typescript
Research direction
Start in packages/web/src/features/search/zoektSearcher.ts at createReposMapForChunk, then read the existing zoektSearcher.test.ts setup. Reproduce the case with 100 files sharing one repository_id and count mocked prisma.repo.findUnique calls. Done means one lookup per unique repository within a chunk, while existing streaming-cache behavior remains intact.
Written by the indexing model from the issue text.
Description
Describe the bug
When search returns multiple files from the same repository, createReposMapForChunk performs a separate Prisma repository lookup for each file.
The repository cache is checked inside concurrent Promise.all callbacks, but it is only populated after the database query resolves. Because of this, files from the same uncached repository all miss the cache and start duplicate lookups.
For example, I tested 100 search results from the same repository and observed 100 prisma.repo.findUnique calls instead of 1.
I would expect repository metadata to be fetched once per unique repository and reused for the other results.
This adds unnecessary database work to the search path, especially when many results come from the same repository.
To reproduce
Using the existing zoektSearcher.test.ts setup:
Return 100 files with the same repository_id.
Mock prisma.repo.findUnique and count the calls.
Run zoektSearch.
findUnique is called 100 times, even though all files belong to one repository.
I also tested two repositories:
100 files from 1 repository → 100 lookups
100 files split across 2 repositories → 100 lookups
For streaming search, the cache works across completed chunks. A second chunk containing files from an already cached repository makes 0 additional lookups. The duplicate lookups happen within the same chunk.
Sourcebot deployment information
Sourcebot version: Local development build from current main
Additional information
Relevant code:
packages/web/src/features/search/zoektSearcher.ts
Function:
createReposMapForChunk
The same search path is also used by Ask Sourcebot tools such as grep and glob.
I haven't measured the production latency impact, so the confirmed issue here is the redundant database work rather than a specific search latency regression.
- Dominant language
- TypeScript
- Stars
- 3.9k
- Forks
- 374
- Avg merge
- 21h 18m
- Merged PRs (30d)
- 39
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from sourcebot-dev/sourcebot
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
sourcebot-dev/sourcebot#1633 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
sourcebot-dev/sourcebot#1384 · 4 comments ·
-
ask_sb bug
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
sourcebot-dev/sourcebot#1137 · 4 comments ·
-
bug triage needed
Difficulty 3/5 1-2 days Newbie friendliness 48/100
sourcebot-dev/sourcebot#1661 · 1 comment ·
-
Feature
Difficulty 4/5 3-5 days Newbie friendliness 50/100
sourcebot-dev/sourcebot#1659 · 1 comment ·
All issues in sourcebot-dev/sourcebot
Similar issues
-
clawsweeper:linked-pr-open clawsweeper:no-new-fix-pr clawsweeper:source-repro impact:message-loss issue-rating: 🦞 diamond lobster maturity:stable P2
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Eynzof/Hermes-CN-Desktop#616 ·
-
ZCode 3.14.3 に対応する Open
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
supermomonga/zcode-acp#24 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 76/100
growthbook/growthbook#7100 ·
-
triage
Difficulty 1/5 1-3 hours Newbie friendliness 88/100