[bug] Index state not consistent with repo state

[gaeljw]

Describe the bug

Hello folks,

For a few days we've observed that the search queries return results that are inconsistent with the actual code state (both in the source Git repos and in the Sourcebot code browser).

For instance a query requests<3 was returning 3 repos matching and showing in preview the string requests<3 but when browsing to the code (in Sourcebot) it displayed requests<2.29.

To reproduce

Unfortunately no reproduction scenario.

Sourcebot deployment information

Sourcebot version (e.g. v3.0.1): 4.10.30

Additional information

• Triggering a re-sync of the Git repositories didn't change the situation.
• Removing all indexes files without restarting the Sourcebot instance didn't change the situation. That's actually surprising to me, but I guess indexes are in memory as well?
• After restart (and having removed all indexes files), the situation is consistent again.

I found some errors in logs that may be related but this is just a guess:

Error: HEAD^{commit}
fatal: ambiguous argument 'HEAD^{commit}': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

    at Object.action (file:///app/node_modules/simple-git/dist/esm/index.js:4462:25)
    at PluginStore.exec (file:///app/node_modules/simple-git/dist/esm/index.js:4501:25)
    at file:///app/node_modules/simple-git/dist/esm/index.js:1369:43
    at new Promise (<anonymous>)
    at GitExecutorChain.handleTaskData (file:///app/node_modules/simple-git/dist/esm/index.js:1367:16)
    at GitExecutorChain.<anonymous> (file:///app/node_modules/simple-git/dist/esm/index.js:1351:44)
    at Generator.next (<anonymous>)
    at fulfilled (file:///app/node_modules/simple-git/dist/esm/index.js:45:24)
    at process.processTicksAndRejections (node:internal/process/task_queues:103:5)

Unable to find repository "gitlab.mycompany.net/somegroup/somerepo" in database for file "xxx.ini". This can happen when a search shard exists for a repository that does not exist in the database. See https://github.com/sourcebot-dev/sourcebot/issues/669 for more details. Skipping file...

(This one is actually about an archived repository, probably unrelated)

I observed the inconsistencies in other repos than somegroup/somerepo and didn't find any log about it.

[brendan-kellam]

Hey @gaeljw I'm looking into this and trying to get a reproduction case. Quick sanity check: do you have multi-branch indexing enabled for the repository you are seeing the issue with?

Additionally, in your example, was the change requests<2.29 introduced before or after requests<3?

Is the Error: HEAD^{commit} error occurring on one of the repositories you have noticed this bug on?

[gaeljw]

do you have multi-branch indexing enabled for the repository you are seeing the issue with?

No, single branch.

Additionally, in your example, was the change requests<2.29 introduced before or after requests<3?

After. The indexes were late in comparison to the actual code state (both in the source repo and in Sourcebot browse).

Is the Error: HEAD^{commit} error occurring on one of the repositories you have noticed this bug on?

In the end, I'm pretty sure it's unrelated. Looks like it's for one of our repo that doesn't contain any code. I didn't know this was even possible. A GitLab project where there's zero commit. You can ignore this error IMHO.

[brendan-kellam]

In the end, I'm pretty sure it's unrelated. Looks like it's for one of our repo that doesn't contain any code. I didn't know this was even possible. A GitLab project where there's zero commit. You can ignore this error IMHO.

Ah yea I've seen this issue before. Opened #914 to handle this case

Removing all indexes files without restarting the Sourcebot instance didn't change the situation. That's actually surprising to me, but I guess indexes are in memory as well?

This provides a good explanation of what is going on:
https://app.sourcebot.dev/~/chat/cmlvbrvn70005nu7x1leqb6q6

---

Based on your description, it sounds to me that the indexing step is failing, perhaps silently? For the repo's that you are observing this repro case, have the indexing jobs been failing?

[gaeljw]

Based on your description, it sounds to me that the indexing step is failing, perhaps silently? For the repo's that you are observing this repro case, have the indexing jobs been failing?

I don't have any evidence of that. Nothing in the logs that say so and the repost status in the UI were OK. Even triggering a few forced sync, it didn't change.

I realize this will be tricky to troubleshoot without more data. If this happens again, I'll comment back :)