langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-22 12:36:14 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

Knowledge base retrieval may unexpectedly take a significant amount of time. #21311

New Issue
Closed
opened 2026-02-21 20:11:55 -05:00 by yindo · 15 comments
yindo commented 2026-02-21 20:11:55 -05:00
Owner
Copy Link
Copy Source

Originally created by @dongfangbai-a on GitHub (Dec 26, 2025).

Originally assigned to: @fatelei on GitHub.

Self Checks

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

Dify version

1.11.2

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

During knowledge base retrieval, if the request sent to the vector model fails, the system will wait for several hundred seconds.

✔️ Expected Behavior

If the request fails, it should terminate immediately.

❌ Actual Behavior

Image Image
Originally created by @dongfangbai-a on GitHub (Dec 26, 2025). Originally assigned to: @fatelei on GitHub. ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [x] This is only for bug report, if you would like to ask a question, please head to [Discussions](https://github.com/langgenius/dify/discussions/categories/general). - [x] I have searched for existing issues [search for existing issues](https://github.com/langgenius/dify/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.11.2 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce During knowledge base retrieval, if the request sent to the vector model fails, the system will wait for several hundred seconds. ### ✔️ Expected Behavior If the request fails, it should terminate immediately. ### ❌ Actual Behavior <img width="964" height="288" alt="Image" src="https://github.com/user-attachments/assets/92c1d97b-e940-4b97-9d7d-85a9077edea3" /> <img width="404" height="736" alt="Image" src="https://github.com/user-attachments/assets/533a902c-efd2-415e-ac4f-45cc7ba8a0d7" />
yindo added the 🐞 bug label 2026-02-21 20:11:55 -05:00
yindo closed this issue 2026-02-21 20:11:55 -05:00
yindo commented 2026-02-21 20:11:55 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Dec 26, 2025):

Hi @liujia0422! I'm Dosu and I’m helping the dify team.

The long delay you’re seeing when a vector model request fails during knowledge base retrieval is due to how Dify handles retrieval tasks internally. The retrieval logic uses thread pools and waits for all retrieval threads to finish or hit a fixed timeout (typically 300 seconds per retrieval batch) before raising any errors. If a vector model request fails quickly (like a 502 error), the system still waits for the full timeout period before reporting the failure, which matches the ~302 second delays in your logs. There’s currently no mechanism to terminate all retrieval tasks immediately on the first failure—errors are only raised after all threads complete or timeout, causing the hang you observed. This behavior is set in the retrieval service code and is not configurable via environment variables or settings right now.

If you want to reduce the impact, you can try lowering the relevant timeout values in your deployment (for example, QDRANT_CLIENT_TIMEOUT for Qdrant requests), but this won’t affect the higher-level thread pool wait. The best workaround is to ensure your vector database and embedding provider are correctly configured and healthy, as misconfigurations can cause these silent failures and long waits. Improving error propagation and early cancellation would require a code change in the retrieval service logic.

References:

To reply, just mention @dosu.

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

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Dec 26, 2025): <!-- Greeting --> Hi @liujia0422! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the dify team. <!-- Answer --> The long delay you’re seeing when a vector model request fails during knowledge base retrieval is due to how Dify handles retrieval tasks internally. The retrieval logic uses thread pools and waits for all retrieval threads to finish or hit a fixed timeout (typically 300 seconds per retrieval batch) before raising any errors. If a vector model request fails quickly (like a 502 error), the system still waits for the full timeout period before reporting the failure, which matches the ~302 second delays in your logs. There’s currently no mechanism to terminate all retrieval tasks immediately on the first failure—errors are only raised after all threads complete or timeout, causing the hang you observed. This behavior is set in the retrieval service code and is not configurable via environment variables or settings right now. If you want to reduce the impact, you can try lowering the relevant timeout values in your deployment (for example, `QDRANT_CLIENT_TIMEOUT` for Qdrant requests), but this won’t affect the higher-level thread pool wait. The best workaround is to ensure your vector database and embedding provider are correctly configured and healthy, as misconfigurations can cause these silent failures and long waits. Improving error propagation and early cancellation would require a code change in the retrieval service logic. References: - [RetrievalService thread pool and timeout logic](https://github.com/langgenius/dify/blob/f610f6895f3cd0fe3a1a47b68cb3136f4a250b21/api/core/rag/datasource/retrieval_service.py#L40-L749) - [Qdrant vector store timeout config](https://github.com/langgenius/dify/blob/f610f6895f3cd0fe3a1a47b68cb3136f4a250b21/api/core/rag/datasource/vdb/qdrant/qdrant_vector.py#L56-L488) - [Docker config and troubleshooting tips](https://github.com/langgenius/dify-docs/issues/397) <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/c2675e71-2ccc-434f-ac8d-490a3ac7697a?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/c2675e71-2ccc-434f-ac8d-490a3ac7697a?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/c2675e71-2ccc-434f-ac8d-490a3ac7697a?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/c2675e71-2ccc-434f-ac8d-490a3ac7697a?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/c2675e71-2ccc-434f-ac8d-490a3ac7697a?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/c2675e71-2ccc-434f-ac8d-490a3ac7697a?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/c2675e71-2ccc-434f-ac8d-490a3ac7697a?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=The%20long%20delay%20you%E2%80%99re%20seeing%20when%20a%20vector%20model%20request%20fails%20during%20knowledge%20base%20retrieval%20is%20due%20to%20how%20Dify%20handles%20retrieval%20tasks%20internally.%20The%20retrieval%20logic%20uses%20thread%20pools%20and%20waits%20for%20all%20retrieval%20threads%20to%20finish%20or%20hit%20a%20fixed%20timeout%20%28typically%20300%20seconds%20per%20retrieval%20batch%29%20before%20raising%20any%20errors.%20If%20a%20vector%20model%20request%20fails%20quickly%20%28like%20a%20502%20error%29%2C%20the%20system%20still%20waits%20for%20the%20full%20timeout%20period%20before%20reporting%20the%20failure%2C%20which%20matches%20the%20~302%20second%20delays%20in%20your%20logs.%20There%E2%80%99s%20currently%20no%20mechanism%20to%20terminate%20all%20retrieval%20tasks%20immediately%20on%20the%20first%20failure%E2%80%94errors%20are%20only%20raised%20after%20all%20threads%20complete%20or%20timeout%2C%20causing%20the%20hang%20you%20observed.%20This%20behavior%20is%20set%20in%20the%20retrieval%20service%20code%20and%20is%20not%20configurable%20via%20environment%20variables%20or%20settings%20right%20now.%20%0A%0AIf%20you%20want%20to%20reduce%20the%20impact%2C%20you%20can%20try%20lowering%20the%20relevant%20timeout%20values%20in%20your%20deployment%20%28for%20example%2C%20%60QDRANT_CLIENT_TIMEOUT%60%20for%20Qdrant%20requests%29%2C%20but%20this%20won%E2%80%99t%20affect%20the%20higher-level%20thread%20pool%20wait.%20The%20best%20workaround%20is%20to%20ensure%20your%20vector%20database%20and%20embedding%20provider%20are%20correctly%20configured%20and%20healthy%2C%20as%20misconfigurations%20can%20cause%20these%20silent%20failures%20and%20long%20waits.%20Improving%20error%20propagation%20and%20early%20cancellation%20would%20require%20a%20code%20change%20in%20the%20retrieval%20service%20logic.%20%0A%0AReferences%3A%20%20%0A-%20%5BRetrievalService%20thread%20pool%20and%20timeout%20logic%5D%28https%3A//github.com/langgenius/dify/blob/f610f6895f3cd0fe3a1a47b68cb3136f4a250b21/api/core/rag/datasource/retrieval_service.py%23L40-L749%29%20%20%0A-%20%5BQdrant%20vector%20store%20timeout%20config%5D%28https%3A//github.com/langgenius/dify/blob/f610f6895f3cd0fe3a1a47b68cb3136f4a250b21/api/core/rag/datasource/vdb/qdrant/qdrant_vector.py%23L56-L488%29%20%20%0A-%20%5BDocker%20config%20and%20troubleshooting%20tips%5D%28https%3A//github.com/langgenius/dify-docs/issues/397%29)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/30225)
yindo commented 2026-02-21 20:11:55 -05:00
Author
Owner
Copy Link
Copy Source

@dongfangbai-a commented on GitHub (Dec 26, 2025):

There will always be request failures caused by network fluctuations or other unexpected incidents, and the time cost of a single failure is currently too high. We hope to optimize this.

@dongfangbai-a commented on GitHub (Dec 26, 2025): There will always be request failures caused by network fluctuations or other unexpected incidents, and the time cost of a single failure is currently too high. We hope to optimize this.
yindo commented 2026-02-21 20:11:55 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Dec 26, 2025):

The long delays you’re seeing are caused by how Dify’s retrieval logic waits for all retrieval threads to finish or hit a fixed timeout (usually 300 seconds) before surfacing any errors—even if a vector model request fails immediately. This means a single network glitch or backend failure can block the whole retrieval for several minutes, as there’s no mechanism to cancel or terminate other tasks early on error.

To optimize this, you’d need to change the retrieval service and DatasetRetrieval logic to propagate exceptions as soon as any thread fails. For example, you could use concurrent.futures.as_completed to inspect each future as it finishes, and if any raises an exception, cancel the remaining futures or signal other threads to stop. Introducing a shared cancellation flag or event, and checking it in each worker, would allow the system to abort quickly on the first failure. This would significantly reduce the time cost of a single failure and make the system more resilient to network issues and backend errors.

Currently, neither the retrieval service nor DatasetRetrieval implements this kind of early termination or cancellation logic—they only collect exceptions and raise them after all threads complete or timeout, which is why you see the long waits. Improving this would require code changes in both classes to support early error propagation and task cancellation.
You can review the relevant code in RetrievalService and DatasetRetrieval.

If you want to contribute or patch this, focus on surfacing exceptions as soon as they occur and cancelling outstanding tasks in the thread pools. This will help Dify handle transient failures much more efficiently.

To reply, just mention @dosu.

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

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Dec 26, 2025): <!-- Answer --> The long delays you’re seeing are caused by how Dify’s retrieval logic waits for all retrieval threads to finish or hit a fixed timeout (usually 300 seconds) before surfacing any errors—even if a vector model request fails immediately. This means a single network glitch or backend failure can block the whole retrieval for several minutes, as there’s no mechanism to cancel or terminate other tasks early on error. To optimize this, you’d need to change the retrieval service and DatasetRetrieval logic to propagate exceptions as soon as any thread fails. For example, you could use `concurrent.futures.as_completed` to inspect each future as it finishes, and if any raises an exception, cancel the remaining futures or signal other threads to stop. Introducing a shared cancellation flag or event, and checking it in each worker, would allow the system to abort quickly on the first failure. This would significantly reduce the time cost of a single failure and make the system more resilient to network issues and backend errors. Currently, neither the retrieval service nor DatasetRetrieval implements this kind of early termination or cancellation logic—they only collect exceptions and raise them after all threads complete or timeout, which is why you see the long waits. Improving this would require code changes in both classes to support early error propagation and task cancellation. You can review the relevant code in [RetrievalService](https://github.com/langgenius/dify/blob/f610f6895f3cd0fe3a1a47b68cb3136f4a250b21/api/core/rag/datasource/retrieval_service.py#L63-L666) and [DatasetRetrieval](https://github.com/langgenius/dify/blob/f610f6895f3cd0fe3a1a47b68cb3136f4a250b21/api/core/rag/retrieval/dataset_retrieval.py#L77-L1473). If you want to contribute or patch this, focus on surfacing exceptions as soon as they occur and cancelling outstanding tasks in the thread pools. This will help Dify handle transient failures much more efficiently. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/ddcc889f-74bf-4a6a-a6ca-52f09d33a23b?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/ddcc889f-74bf-4a6a-a6ca-52f09d33a23b?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/ddcc889f-74bf-4a6a-a6ca-52f09d33a23b?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/ddcc889f-74bf-4a6a-a6ca-52f09d33a23b?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/ddcc889f-74bf-4a6a-a6ca-52f09d33a23b?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/ddcc889f-74bf-4a6a-a6ca-52f09d33a23b?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/ddcc889f-74bf-4a6a-a6ca-52f09d33a23b?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=The%20long%20delays%20you%E2%80%99re%20seeing%20are%20caused%20by%20how%20Dify%E2%80%99s%20retrieval%20logic%20waits%20for%20all%20retrieval%20threads%20to%20finish%20or%20hit%20a%20fixed%20timeout%20%28usually%20300%20seconds%29%20before%20surfacing%20any%20errors%E2%80%94even%20if%20a%20vector%20model%20request%20fails%20immediately.%20This%20means%20a%20single%20network%20glitch%20or%20backend%20failure%20can%20block%20the%20whole%20retrieval%20for%20several%20minutes%2C%20as%20there%E2%80%99s%20no%20mechanism%20to%20cancel%20or%20terminate%20other%20tasks%20early%20on%20error.%0A%0ATo%20optimize%20this%2C%20you%E2%80%99d%20need%20to%20change%20the%20retrieval%20service%20and%20DatasetRetrieval%20logic%20to%20propagate%20exceptions%20as%20soon%20as%20any%20thread%20fails.%20For%20example%2C%20you%20could%20use%20%60concurrent.futures.as_completed%60%20to%20inspect%20each%20future%20as%20it%20finishes%2C%20and%20if%20any%20raises%20an%20exception%2C%20cancel%20the%20remaining%20futures%20or%20signal%20other%20threads%20to%20stop.%20Introducing%20a%20shared%20cancellation%20flag%20or%20event%2C%20and%20checking%20it%20in%20each%20worker%2C%20would%20allow%20the%20system%20to%20abort%20quickly%20on%20the%20first%20failure.%20This%20would%20significantly%20reduce%20the%20time%20cost%20of%20a%20single%20failure%20and%20make%20the%20system%20more%20resilient%20to%20network%20issues%20and%20backend%20errors.%0A%0ACurrently%2C%20neither%20the%20retrieval%20service%20nor%20DatasetRetrieval%20implements%20this%20kind%20of%20early%20termination%20or%20cancellation%20logic%E2%80%94they%20only%20collect%20exceptions%20and%20raise%20them%20after%20all%20threads%20complete%20or%20timeout%2C%20which%20is%20why%20you%20see%20the%20long%20waits.%20Improving%20this%20would%20require%20code%20changes%20in%20both%20classes%20to%20support%20early%20error%20propagation%20and%20task%20cancellation.%20%20%0AYou%20can%20review%20the%20relevant%20code%20in%20%5BRetrievalService%5D%28https%3A//github.com/langgenius/dify/blob/f610f6895f3cd0fe3a1a47b68cb3136f4a250b21/api/core/rag/datasource/retrieval_service.py%23L63-L666%29%20and%20%5BDatasetRetrieval%5D%28https%3A//github.com/langgenius/dify/blob/f610f6895f3cd0fe3a1a47b68cb3136f4a250b21/api/core/rag/retrieval/dataset_retrieval.py%23L77-L1473%29.%0A%0AIf%20you%20want%20to%20contribute%20or%20patch%20this%2C%20focus%20on%20surfacing%20exceptions%20as%20soon%20as%20they%20occur%20and%20cancelling%20outstanding%20tasks%20in%20the%20thread%20pools.%20This%20will%20help%20Dify%20handle%20transient%20failures%20much%20more%20efficiently.)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/30225)
yindo commented 2026-02-21 20:11:55 -05:00
Author
Owner
Copy Link
Copy Source

@Chenyl-Sai commented on GitHub (Dec 27, 2025):

Hi @liujia0422, did you use the HYBRID_SEARCH mode?
How is the performance of full_text_index_search?
The HYBRID_SEARCH mode waits for both embedding_search and full_text_index_search to finish, or times out after 300 seconds.
Is the performance of full_text_index_search very slow?

@Chenyl-Sai commented on GitHub (Dec 27, 2025): Hi @liujia0422, did you use the `HYBRID_SEARCH` mode? How is the performance of `full_text_index_search`? The `HYBRID_SEARCH` mode waits for both `embedding_search` and `full_text_index_search` to finish, or times out after 300 seconds. Is the performance of `full_text_index_search` very slow?
yindo commented 2026-02-21 20:11:56 -05:00
Author
Owner
Copy Link
Copy Source

@dongfangbai-a commented on GitHub (Dec 27, 2025):

Hi @liujia0422, did you use the mode? How is the performance of ? The mode waits for both and to finish, or times out after 300 seconds. Is the performance of very slow?HYBRID_SEARCH``full_text_index_search``HYBRID_SEARCH``embedding_search``full_text_index_search``full_text_index_search

我是用的通用分段

@dongfangbai-a commented on GitHub (Dec 27, 2025): > Hi [@liujia0422](https://github.com/liujia0422), did you use the mode? How is the performance of ? The mode waits for both and to finish, or times out after 300 seconds. Is the performance of very slow?`HYBRID_SEARCH``full_text_index_search``HYBRID_SEARCH``embedding_search``full_text_index_search``full_text_index_search` 我是用的通用分段
yindo commented 2026-02-21 20:11:56 -05:00
Author
Owner
Copy Link
Copy Source

@dongfangbai-a commented on GitHub (Dec 27, 2025):

我是用的通用分段

@dongfangbai-a commented on GitHub (Dec 27, 2025): 我是用的通用分段
yindo commented 2026-02-21 20:11:56 -05:00
Author
Owner
Copy Link
Copy Source

@Chenyl-Sai commented on GitHub (Dec 27, 2025):

Image

Not the Chunk Structure——I mean the Retrieval Setting. Did you use the Hybrid Search?

I think the search strategy could be changed to FIRST_EXCEPTION, so that the search can return early when any error occurs.
Currently, it uses ALL_COMPLETED:

concurrent.futures.wait(futures, timeout=300, return_when=concurrent.futures.ALL_COMPLETED)
@Chenyl-Sai commented on GitHub (Dec 27, 2025): <img width="1850" height="2336" alt="Image" src="https://github.com/user-attachments/assets/4031cbbc-60c4-4d41-96c7-dc4d5e1f47b9" /> Not the `Chunk Structure`——I mean the `Retrieval Setting`. Did you use the `Hybrid Search`? I think the search strategy could be changed to `FIRST_EXCEPTION`, so that the search can return early when any error occurs. Currently, it uses `ALL_COMPLETED`: ``` concurrent.futures.wait(futures, timeout=300, return_when=concurrent.futures.ALL_COMPLETED) ```
yindo commented 2026-02-21 20:11:56 -05:00
Author
Owner
Copy Link
Copy Source

@dongfangbai-a commented on GitHub (Dec 27, 2025):

Image Image 这是我的知识库和工作流里的检索设置
@dongfangbai-a commented on GitHub (Dec 27, 2025): <img width="1230" height="823" alt="Image" src="https://github.com/user-attachments/assets/ba6dc96d-1510-4280-bf7e-d1e98dd40e80" /> <img width="917" height="793" alt="Image" src="https://github.com/user-attachments/assets/92dca2e3-9e10-4cf9-af8a-b780bf042419" /> 这是我的知识库和工作流里的检索设置
yindo commented 2026-02-21 20:11:56 -05:00
Author
Owner
Copy Link
Copy Source

@dongfangbai-a commented on GitHub (Dec 27, 2025):

@Chenyl-Sai 我的检索设置和你的截图中的设置是一样的

@dongfangbai-a commented on GitHub (Dec 27, 2025): @Chenyl-Sai 我的检索设置和你的截图中的设置是一样的
yindo commented 2026-02-21 20:11:56 -05:00
Author
Owner
Copy Link
Copy Source

@Chenyl-Sai commented on GitHub (Dec 27, 2025):

If you use Hybrid Search, there are several steps. First, embedding_search is used for semantic search, and full_text_index_search is used for full-text search. Then the system waits for both threads to finish.

I’d like to understand which step corresponds to the second picture you mentioned.
Also, have you observed any performance issues with the other call?

@Chenyl-Sai commented on GitHub (Dec 27, 2025): If you use Hybrid Search, there are several steps. First, `embedding_search` is used for semantic search, and `full_text_index_search` is used for full-text search. Then the system waits for both threads to finish. I’d like to understand which step corresponds to the second picture you mentioned. Also, have you observed any performance issues with the other call?
yindo commented 2026-02-21 20:11:56 -05:00
Author
Owner
Copy Link
Copy Source

@dongfangbai-a commented on GitHub (Dec 27, 2025):

如果您使用混合搜索，有几个步骤。首先， embedding_search 用于语义搜索，以及 full_text_index_search 用于全文搜索。然后，系统等待两个线程完成。

我想知道你提到的第二张图片对应的是哪个步骤。 另外，您是否观察到其他呼叫存在任何性能问题？

第二张照片是在工作流中使用知识库节点接入第一张图片里的知识库后，在工作流的知识库节点中设置的召回设置。我有两个工作流，都遇到过工作流长时间等待知识库召回的问题

@dongfangbai-a commented on GitHub (Dec 27, 2025): > 如果您使用混合搜索，有几个步骤。首先， `embedding_search` 用于语义搜索，以及 `full_text_index_search` 用于全文搜索。然后，系统等待两个线程完成。 > > 我想知道你提到的第二张图片对应的是哪个步骤。 另外，您是否观察到其他呼叫存在任何性能问题？ 第二张照片是在工作流中使用知识库节点接入第一张图片里的知识库后，在工作流的知识库节点中设置的召回设置。我有两个工作流，都遇到过工作流长时间等待知识库召回的问题
yindo commented 2026-02-21 20:11:56 -05:00
Author
Owner
Copy Link
Copy Source

@Chenyl-Sai commented on GitHub (Dec 27, 2025):

Sorry, I mean this picture

Image
@Chenyl-Sai commented on GitHub (Dec 27, 2025): Sorry, I mean this picture <img width="756" height="1418" alt="Image" src="https://github.com/user-attachments/assets/bb1f80e6-eac8-4e4f-9660-5c1bc9252be1" />
yindo commented 2026-02-21 20:11:56 -05:00
Author
Owner
Copy Link
Copy Source

@dongfangbai-a commented on GitHub (Dec 27, 2025):

Sorry, I mean this picture

Image

这张图片是我从模型供应商控制台，找到的向量模型请求响应失败的图片。我排查发现一旦向量模型请求没有成功，知识库的检索就要等待300秒左右才会结束

@dongfangbai-a commented on GitHub (Dec 27, 2025): > Sorry, I mean this picture > > <img alt="Image" width="756" height="1418" src="https://private-user-images.githubusercontent.com/9086842/530515676-bb1f80e6-eac8-4e4f-9660-5c1bc9252be1.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3NjY4ODkzNDgsIm5iZiI6MTc2Njg4OTA0OCwicGF0aCI6Ii85MDg2ODQyLzUzMDUxNTY3Ni1iYjFmODBlNi1lYWM4LTRlNGYtOTY2MC01YzFiYzkyNTJiZTEucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI1MTIyOCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNTEyMjhUMDIzMDQ4WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9Yjg3N2RmMDljNTgyZmRlNzBjY2U0NzJlYjVlNDI0MmExMDY4MjJkNTMyMzA4ZGExNDA1NTJkYmFhZWI0MTNhMCZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QifQ.NAq_iTY4N_A98BHqatpM7DpDkUXXyk7ayVhE20BOCt0"> 这张图片是我从模型供应商控制台，找到的向量模型请求响应失败的图片。我排查发现一旦向量模型请求没有成功，知识库的检索就要等待300秒左右才会结束
yindo commented 2026-02-21 20:11:56 -05:00
Author
Owner
Copy Link
Copy Source

@dongfangbai-a commented on GitHub (Dec 28, 2025):

@fatelei Why not try requesting a retry? I think retrying once is better than exiting directly.

@dongfangbai-a commented on GitHub (Dec 28, 2025): @fatelei Why not try requesting a retry? I think retrying once is better than exiting directly.
yindo commented 2026-02-21 20:11:56 -05:00
Author
Owner
Copy Link
Copy Source

@fatelei commented on GitHub (Dec 28, 2025):

@fatelei Why not try requesting a retry? I think retrying once is better than exiting directly.

retry depends on manual retry

@fatelei commented on GitHub (Dec 28, 2025): > [@fatelei](https://github.com/fatelei) Why not try requesting a retry? I think retrying once is better than exiting directly. retry depends on manual retry
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Knowledge Pipeline
Proposal
WIP
cloud
dependencies
feat:webapp
good first issue
outdated
performance
pull-request
Mirrored from GitHub Pull Request
 python:uv
refactor
size:L
stale
status: accepting prs
status: blocked
status: in discussion
stt & tts
vulnerablity
web
wont-fix
🌊 feat:workflow
🌚 invalid
🐞 bug
👻 feat:rag
💪 enhancement
📚 documentation
🔨 feat:tools
🙋‍♂️ question
🙏 help wanted
🤔 cant-reproduce
🤖 feat:agent
No Label 🐞 bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#21311
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?