[Bug] Knowledge base embedding_model_id and tool index_names are not persisted

Nexent Version

v2.1.1

Problem Description

During local deployment and agent creation, I encountered cases where the frontend showed that configuration was completed, but the backend database or the published agent version did not actually contain the required configuration.

The two main issues were:

1. A knowledge base was created from the frontend, but knowledge_record_t.embedding_model_id and embedding_model_name were empty. As a result, document indexing failed even though the embedding model bge-m3 was shown as available in Model Management.

2. The agent frontend showed knowledge_base_search as selected/configured, but the published agent version still had index_names = null. As a result, the chat page could not correctly use the knowledge base.

Relevant backend errors:

Embedding API error: 'NoneType' object has no attribute 'get_embeddings'

Embedding model is required for knowledge_base_search but index_names is empty

This made it difficult to determine whether the problem came from file parsing, embedding model configuration, knowledge base binding, tool configuration, or published agent version persistence.

Reproduction Steps

1. Deploy Nexent v2.1.1 locally with Docker on macOS.
2. Add an embedding model in Model Management.
3. Confirm the embedding model bge-m3 is shown as available.
4. Create a new knowledge base from the frontend.
5. Upload PDF / Markdown / PPT files.
6. The files may fail to index if the knowledge base record does not contain embedding_model_id.
7. Check the database and observe that knowledge_record_t.embedding_model_id and embedding_model_name are empty.
8. Create a new agent.
9. Add knowledge_base_search as a tool.
10. Configure the tool to use the knowledge base.
11. Save the tool configuration.
12. Save and publish the agent.
13. Open the chat page and select the published agent.
14. Send a knowledge-base-related query.
15. The agent may fail if the published tool config still has index_names = null.

Temporary workaround used locally:

1. Manually bind the knowledge base record to the available bge-m3 embedding model.
2. Delete the failed files and re-upload them.
3. Reopen the knowledge_base_search tool configuration.
4. Explicitly set index_names, top_k, search_mode, and rerank.
5. Save tool config.
6. Save the agent.
7. Publish a new version.

After these steps, document indexing and agent chat worked correctly.

Additional Information

Expected behavior:

1. When creating or using a knowledge base, Nexent should either:

   • automatically bind the current available embedding model;
   • or require the user to select an embedding model;
   • or block file upload with a clear message if no embedding model is bound.

2. When publishing an agent, if knowledge_base_search is selected but index_names is empty, Nexent should:

   • block publishing;
   • show a clear validation error such as Please select a knowledge base for knowledge_base_search;
   • or automatically validate the published tool configuration before publishing.

3. The system should not allow publishing an agent that fails at runtime because a required tool parameter is missing.

4. The UI should make the difference clearer between:

   • Save tool config
   • Save agent
   • Publish version

5. It would be helpful to add a debug-friendly display of the effective published tool configuration.

Environment:

• Nexent version: v2.1.1
• Deployment: Local Docker deployment on macOS
• Browser: Chrome
• Model provider: SiliconFlow
• LLM: Qwen3.5-9B
• Embedding model: bge-m3

No API keys, .env files, database files, or private course materials are included in this issue.

Trace the backend paths for knowledge-base creation and agent tool save/publish, focusing on knowledge_record_t.embedding_model_id, embedding_model_name, and the published knowledge_base_search index_names value. Reproduce the Docker deployment flow and inspect the persisted records and published configuration; done means required values are retained or publishing/upload is clearly blocked with validation.