After upgrading Dify from 1.8.0 to 1.10.1-fix.1, the knowledge base responses are inaccurate, and the summon test is reporting errors.

[zhw1992]

Self Checks

• [x] I have read the Contributing Guide and Language Policy.
• [x] This is only for bug report, if you would like to ask a question, please head to Discussions.
• [x] I have searched for existing issues search for existing issues, including closed ones.
• [x] I confirm that I am using English to submit this report, otherwise it will be closed.
• [x] 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
• [x] Please do not modify this template :) and fill in all the required fields.

Dify version

1.10.1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

After upgrading Dify from 1.8.0 to 1.10.1-fix.1, the knowledge base responses are inaccurate, and the summon test is reporting errors.

Error message as follows: Query call with protocol GRPC search failed with message extract target vectors: class Vector_index_37fd4f77_77c0_4ac8_bfb3_c84a4b8f383d_Node does not have named vector default configured. Available named vectors map[].

✔️ Expected Behavior

Expected that after the upgrade, it would work the same as the original version and be able to answer normally.

❌ Actual Behavior

No response

[dosubot[bot]]

The error happens because Dify 1.10.1+ requires each vector index to have a named vector configuration called "default", which older knowledge bases (from 1.8.0 and earlier) lack after upgrade. There is no automated migration script for this change, so manual re-indexing is needed to restore search and recall functionality.

To fix it, re-upload or re-ingest your knowledge base documents in Dify 1.10.1. This will recreate the vector indexes with the required "default" named vector metadata. For large knowledge bases, you can script the export and re-import to trigger re-indexing. If you use custom ingestion scripts, ensure the vector payload uses {"default": embedding}.

A quick workaround is to change the embedding model of the knowledge base (switch to another model and back), which triggers automatic re-indexing and resolves the error, but this may require downtime and is less ideal for large datasets. If you need immediate access and cannot re-index right now, temporarily downgrading to Dify 1.9.1 is an option until migration is complete.

For vector backends like Weaviate, Qdrant, or TiDB-on-Qdrant, collections must be rebuilt to include the "default" named vector after upgrade. If you use Weaviate, check for case sensitivity mismatches between class/node names in Dify and Weaviate, as this can also cause the same error—names must match exactly in case in both storage and queries.

References:

• Discussion: Vector index structure change and re-indexing required
• Discussion: Manual re-indexing and backend migration guides
• Issue: Rebuilding index by switching embedding model
• Issue: Weaviate migration and case sensitivity

To reply, just mention @dosu.

---

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

   

[rechardwang]

How to rebuild all indexes using scripts? Does the official documentation provide such scripts?

[damirdine]

@rechardwang You can just change the embedding model in the knowledge base settings to another model, save it, then switch back to the previous embedding model and save again. That worked for me.

[YuLionel]

I attempted to resolve the issue by changing the embedding model, saving the settings, then switching back to the original embedding model and saving again, but unfortunately, this approach didn't work. After several repeated attempts with the same method, I was on the verge of giving up. However, I decided to try disabling and then re-enabling the files within the knowledge base. Surprisingly, this resolved the problem.

I suspect that either the disable/enable action triggered the necessary reindexing process, or perhaps the initial reindexing operation simply took longer than expected to complete and required additional waiting time. It's possible that the system needed that extra processing period or the specific action of toggling file states to properly initiate the vector rebuild with the new named vector configuration.

[pengzhen-developer]

I attempted to resolve the issue by changing the embedding model, saving the settings, then switching back to the original embedding model and saving again, but unfortunately, this approach didn't work. After several repeated attempts with the same method, I was on the verge of giving up. However, I decided to try disabling and then re-enabling the files within the knowledge base. Surprisingly, this resolved the problem.我尝试通过更改嵌入模型、保存设置，然后再切换回原始嵌入模型并再次保存来解决这个问题，但很遗憾，这种方法并没有奏效。多次尝试相同方法后，我几乎要放弃了。然而，我决定尝试禁用知识库中的文件，然后再重新启用。出乎意料的是，这竟然解决了问题。

I suspect that either the disable/enable action triggered the necessary reindexing process, or perhaps the initial reindexing operation simply took longer than expected to complete and required additional waiting time. It's possible that the system needed that extra processing period or the specific action of toggling file states to properly initiate the vector rebuild with the new named vector configuration.我怀疑可能是禁用/启用操作触发了必要的重新索引过程，或者初始重新索引操作耗时超出预期，需要额外的等待时间。系统可能需要额外的处理时间，或者需要切换文件状态的特定操作，才能使用新的命名向量配置正确启动向量重建。

tks，resolved