Error getting context items from codebase: Error: SQLITE_ERROR: no such table: lance_db_cache

[erikdemarco]

Before submitting your bug report

• [X] I believe this is a bug. I'll try to join the Continue Discord for questions
• [X] I'm not able to find an open issue that reports the same bug
• [X] I've seen the troubleshooting guide on the Continue Docs

Relevant environment info

- OS:Linux Mint 22
- Continue:0.9.214
- IDE:VsCode 1.94
- Model:Gemini 1.5 Flash
- config.json:
  
{
  "models": [

    {
      "title": "Gemini 1.5 Flash",
      "model": "gemini-1.5-flash-latest",
      "contextLength": 1000000,
      "provider": "gemini"
    }
  ],

  "tabAutocompleteModel": {
    "title": "Codestral",
    "provider": "mistral",
    "model": "codestral-latest"
  },
 

  "embeddingsProvider": {
    "provider": "voyage",
    "model": "voyage-code-2",
  },

  "reranker": {
    "name": "voyage",
    "params": {
      "model": "rerank-1"
    }
  },



  "contextProviders": [
    { 
      "name": "open"
    },
    {
      "name": "codebase",
      "params": {
        "nRetrieve": 25,
        "nFinal": 5,
        "useReranking": true
      }
    }
  ]




}

Description

Whenever I run a query using the @codebase tag Continue is unable to retrieve any contextual information. It fails with the error - Error getting context items from codebase: Error: SQLITE_ERROR: no such table: lance_db_cache

I know some of you getting sick of this error again, but its still happen. I love using continue, this is the only reason i keep coming back to codeium. I thought this error already disappear soon. But it still exist. What i have tried so far: -) continue.dev stable and pre-release version. -) embedding model i tried: voyage-code-2, transformers.js -) turn off and on reranking

To reproduce

1. Open the Continue.dev panel
2. Ensure indexing is up to date (you can click the force index button to ensure this)
3. Run @codebase tell me about this code It will fail.

Log output

[Extension Host] Error retrieving from FTS: Error: SQLITE_ERROR: no such table: fts
--> in Database#all('SELECT fts_metadata.chunkId, fts_metadata.path, fts.content, rank\n' +
  '    FROM fts\n' +
  '    JOIN fts_metadata ON fts.rowid = fts_metadata.id\n' +
  '    JOIN chunk_tags ON fts_metadata.chunkId = chunk_tags.chunkId\n' +
  `    WHERE fts MATCH '"review" OR "my" OR "code"' AND chunk_tags.tag IN (?)\n` +
  '      \n' +
  '    ORDER BY rank\n' +
  '    LIMIT ?', [ '/home/Desktop/tmp/vite/xxx::NONE::chunks', 25 ], [Function (anonymous)])
	at new Promise (<anonymous>)

[Extension Host] Table not found in LanceDB homeDesktoptmpvitexxxNONEvectordb_TransformersJsEmbeddingsProviderall-MiniLM-L6-v2

Error getting context items from codebase: Error: SQLITE_ERROR: no such table: lance_db_cache

[Patrick-Erichsen]

Hi @erikdemarco , sorry to hear you've run into this issue multiple times.

Have you tried clearing you index folder, e.g. rm -rf ~/.continue/index?

Running the "Force re-index" doesn't actually clear the contents of that folder. Was that the behavior you would have expected?

[erikdemarco]

@Patrick-Erichsen i tried your command, but it still same.

console.ts:137 [Extension Host] Error retrieving from FTS: Error: SQLITE_ERROR: no such table: fts
--> in Database#all('SELECT fts_metadata.chunkId, fts_metadata.path, fts.content, rank\n' +
  '    FROM fts\n' +
  '    JOIN fts_metadata ON fts.rowid = fts_metadata.id\n' +
  '    JOIN chunk_tags ON fts_metadata.chunkId = chunk_tags.chunkId\n' +
  `    WHERE fts MATCH '"review" OR "my" OR "code" OR "structure"' AND chunk_tags.tag IN (?)\n` +
  '      \n' +
  '    ORDER BY rank\n' +
  '    LIMIT ?', [ '/home/xxx/Desktop/tmp::NONE::chunks', 25 ], [Function (anonymous)])
	at new Promise (<anonymous>)
G_i @ console.ts:137
$logExtensionHostMessage @ mainThreadConsole.ts:39
S @ rpcProtocol.ts:458
Q @ rpcProtocol.ts:443
M @ rpcProtocol.ts:373
L @ rpcProtocol.ts:299
(anonymous) @ rpcProtocol.ts:161
B @ event.ts:1242
fire @ event.ts:1273
fire @ ipc.net.ts:652
l.onmessage @ localProcessExtensionHost.ts:378
console.ts:137 

[Extension Host] Table not found in LanceDB homexxxDesktoptmpNONEvectordb_TransformersJsEmbeddingsProviderall-MiniLM-L6-v2
G_i @ console.ts:137
$logExtensionHostMessage @ mainThreadConsole.ts:39
S @ rpcProtocol.ts:458
Q @ rpcProtocol.ts:443
M @ rpcProtocol.ts:373
L @ rpcProtocol.ts:299
(anonymous) @ rpcProtocol.ts:161
B @ event.ts:1242
fire @ event.ts:1273
fire @ ipc.net.ts:652
l.onmessage @ localProcessExtensionHost.ts:378
notificationsAlerts.ts:42 

Error getting context items from codebase: Error: SQLITE_ERROR: no such table: lance_db_cache

[Patrick-Erichsen]

Got it, thanks for the follow up.

rm -rf ~/.continue/index generally works to just clear the index and rebuild from scratch so I'm not sure what the issue is here. My only hunch is that it is Linux specific with our FTS table. It might be our naming logic based on this string in the logs: "/home/xxx/Desktop/tmp::NONE::chunks"

[moriartynz]

On my Arch Linux system, it seems to have difficulty with certain files when re-indexing that causes the re-indexing to fail. In particular, it fails on .~lock.* files (I think generated by Libreoffice). It doesn't even get to the LanceDBIndex stage. I think it needs to fail gracefully and continue instead.

[Patrick-Erichsen]

@moriartynz does it ever make sense to index a .~lock.* file? If not, we can just add this to our default ignores. Definitely should be failing more gracefully regardless though.

[jkrauss82]

EDIT: Switching to pre-release v0.9.239 in VS Code seems to has fixed issue 1043 (mentioned in my comment below) and in turn indexing is running currently so far. I will report if it finishes successfully, my codebase is rather large.

EDIT2: It is able to finish indexing successfully on v0.9.239.

---

I am having this problem as well, just installed this extension v0.8.60 on VS Code, Kubuntu 22.04.

I think the problem might be related to this issue and in turn the transformers.js? Because the indexing does not seem to have any sort of precaution and just fails whenever it runs into an error.

Expected behavior would be to skip a line or file which throws an error instead of completely stopping to index. This makes using codebase impossible ATM. I don't think maintaining a default ignore list helps much as there will always be cases out in the wild which are not in the ignore list.

[moriartynz]

@moriartynz does it ever make sense to index a .~lock.* file? If not, we can just add this to our default ignores. Definitely should be failing more gracefully regardless though.

You are correct, lock files do not need to be indexed and can be added to the default ignores. 110% agree that failure should be more graceful. There are bound to be issues with software when set loose in the wild. It really needs to have a way of dealing with single point failures without completely failing in its functionality.

[kunalbhadra-pp]

Getting the same error on MacOS VSCode with local llm.

[geertj]

I am still getting the error Error: SQLITE_ERROR: no such table: lance_db_cache. This is with the latest pre-release (v0.9.241), using SSH-remote from Mac (local) to Linux (remote). If I run the Continue extension remotely on Linux, the error goes away.

[kunalbhadra-pp]

Getting the same error on MacOS VSCode with local llm.

This is resolved now, after refreshing the extension for the entire workspace.

[xiangshoulai]

I have the same problem when using @codebase, has it been solved?

[Patrick-Erichsen]

@xiangshoulai can you try clearing your index? rm -rf ~/.continue/index?

[xiangshoulai]

@xiangshoulai can you try clearing your index? rm -rf ~/.continue/index?

It's been solved，thank you

[souvikpal2000]

@Patrick-Erichsen I'm getting the same error for continue version release-0.9.195

rm -rf ~/.continue/index is not working for me

OS: Windows11

[Patrick-Erichsen]

@souvikpal2000 - can you try upgrading to latest release?

[github-actions[bot]]

This issue hasn't been updated in 90 days and will be closed after an additional 10 days without activity. If it's still important, please leave a comment and share any new information that would help us address the issue.

[github-actions[bot]]

This issue was closed because it wasn't updated for 10 days after being marked stale. If it's still important, please reopen + comment and we'll gladly take another look!