Batches: Search_result_paths can be wrong due to race condition
- Truncate descriptions
Created by: eseliger
Indexed search is constantly playing catch up with commits being pushed to repos. Now, when I add a new commit, it takes a couple seconds to minutes (depending on the repo size) until the latest commit is actually indexed and hence searched when running a search. We knew there can be discrepancies between search results when the preview ran and when the execution starts, so we do persist the commit hash along with the search result paths, but we do not take the commit from the search result, we simply take latest commit on HEAD at the time of resolution. So there’s this discrepancy between commits while zoekt indexes and hence returns search result paths for, where running the search and fetching latest head for a repo returns results for different states.
This also raised two more questions
- what if there are multiple searchable branches configured for a repo
- and what if a user does
r:repo@rev
. Those cases likely also won’t work with search result paths today.
What we want here
Result from a slack conversation here: https://sourcegraph.slack.com/archives/CMMTWQQ49/p1653673036361389
- When a revision is specified, we use that revision
- But only if it is a branch (need to ask gitserver?)
- If it is a tag, we error
- If it is a commit SHA, we ensure it exists on the main branch and we go from there and target main. If not, we error
- When there are multiple branches/SHAs resolved for the same repo, we error
- If there are multiple branches searchable, we don't support that. The behavior is undefined and we document that

