v0.20.0 delete database issue

[jokerLavender]

I is using v0.20.0 version.When I delete a knowledge base, I find that the data related to Elasticsearch has not been deleted. Is it intentional not to delete it

[dosubot[bot]]

Hi @jokerLavender! I'm Dosu and I’m helping the ragflow team.

Yes, this is intentional in v0.20.0. When you delete a knowledge base, RAGFlow deletes all related documents in Elasticsearch that match the kb_id, but it does not remove the Elasticsearch index itself. This is because all knowledge bases under a tenant share one index—deleting the index would affect other knowledge bases, so the index is kept alive by design. The code and comments confirm this approach to avoid data loss for other knowledge bases under the same tenant, though it may leave empty or partially-filled indices after deletions. You can see this logic in the code and documentation here and here.

If deleted content still appears in search results, it’s usually due to incomplete removal from the search index or background sync issues, not intentional retention of data.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[jokerLavender]

When I delete a single file from the knowledge base, the data related to that file still exists in Elasticsearch. Is this a code bug?

[dosubot[bot]]

Yes, this is a code bug. When you delete a single file from the knowledge base in RAGFlow v0.20.0, the system is supposed to remove all related chunks and document data from Elasticsearch. The backend calls logic that deletes Elasticsearch documents matching the file's document ID, as shown in the code for DocumentService.remove_document (source).

However, several users have reported that deleted files still appear in search results, and maintainers have confirmed this is a known issue—often caused by incomplete cleanup, loose error handling, or the lack of cache invalidation (thread, thread). If you use the official API/UI and still see stale data, check backend logs for errors during deletion. Sometimes a full redeploy with cleared volumes is needed to remove lingering state.

Manual deletion of individual files usually triggers the correct cleanup, but if you delete folders, orphaned references can remain due to incomplete recursive cleanup (thread).

In summary: persistent Elasticsearch data after file deletion is not intentional and is considered a bug.

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[jokerLavender]

How long does it take to fix this bug? Thank you