langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-21 20:15:31 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

The Q&A mode always fails. #7409

New Issue
Closed
opened 2026-02-21 18:20:27 -05:00 by yindo · 14 comments
yindo commented 2026-02-21 18:20:27 -05:00
Owner
Copy Link
Copy Source

Originally created by @gongshaojie12 on GitHub (Dec 26, 2024).

Self Checks

  • 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 (我已阅读并同意 Language Policy).
  • [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:）
  • Please do not modify this template :) and fill in all the required fields.

Dify version

0.14.2

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

The configuration after I upload files to the knowledge base is as follows.
image
image

When I click "Save and Process," the following issue occurs.

2024-12-27 02:26:50,448.448 ERROR [Thread-1123 (_format_qa_document)] [http_request.py:181] - Request: https://dashscope.aliyuncs.com/api/v1/services/aigc/multimodal-generation/generation failed, status: 429, message: Requests rate limit exceeded, please try again later.
2024-12-27 02:26:50,450.450 ERROR [Thread-1123 (_format_qa_document)] [qa_index_processor.py:159] - Failed to format qa document
Traceback (most recent call last):
  File "/app/api/core/model_runtime/model_providers/__base/large_language_model.py", line 110, in invoke
    result = self._invoke(
             ^^^^^^^^^^^^^
  File "/app/api/core/model_runtime/model_providers/tongyi/llm/llm.py", line 84, in _invoke
    return self._generate(model, credentials, prompt_messages, model_parameters, tools, stop, stream, user)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/core/model_runtime/model_providers/tongyi/llm/llm.py", line 205, in _generate
    return self._handle_generate_response(model, credentials, response, prompt_messages)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/core/model_runtime/model_providers/tongyi/llm/llm.py", line 220, in _handle_generate_response
    raise ServiceUnavailableError(response.message)
dashscope.common.error.ServiceUnavailableError: Requests rate limit exceeded, please try again later.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/app/api/core/rag/index_processor/processor/qa_index_processor.py", line 146, in _format_qa_document
    response = LLMGenerator.generate_qa_document(tenant_id, document_node.page_content, document_language)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/core/llm_generator/llm_generator.py", line 306, in generate_qa_document
    response = model_instance.invoke_llm(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/core/model_manager.py", line 127, in invoke_llm
    return self._round_robin_invoke(
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/core/model_manager.py", line 310, in _round_robin_invoke
    return function(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/app/api/core/model_runtime/model_providers/__base/large_language_model.py", line 134, in invoke
    raise self._transform_invoke_error(e)
core.model_runtime.errors.invoke.InvokeServerUnavailableError: [tongyi] Server Unavailable Error, Requests rate limit exceeded, please try again later.

How can I resolve this issue?

✔️ Expected Behavior

No response

❌ Actual Behavior

No response

Originally created by @gongshaojie12 on GitHub (Dec 26, 2024). ### Self Checks - [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 (我已阅读并同意 [Language Policy](https://github.com/langgenius/dify/issues/1542)). - [X] [FOR CHINESE USERS] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:） - [X] Please do not modify this template :) and fill in all the required fields. ### Dify version 0.14.2 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce The configuration after I upload files to the knowledge base is as follows. ![image](https://github.com/user-attachments/assets/be543d03-d40b-42df-b51c-bf8c8770a0f1) ![image](https://github.com/user-attachments/assets/b18d8034-5cd2-4b58-9035-62b134695f8b) When I click "Save and Process," the following issue occurs. ``` 2024-12-27 02:26:50,448.448 ERROR [Thread-1123 (_format_qa_document)] [http_request.py:181] - Request: https://dashscope.aliyuncs.com/api/v1/services/aigc/multimodal-generation/generation failed, status: 429, message: Requests rate limit exceeded, please try again later. 2024-12-27 02:26:50,450.450 ERROR [Thread-1123 (_format_qa_document)] [qa_index_processor.py:159] - Failed to format qa document Traceback (most recent call last): File "/app/api/core/model_runtime/model_providers/__base/large_language_model.py", line 110, in invoke result = self._invoke( ^^^^^^^^^^^^^ File "/app/api/core/model_runtime/model_providers/tongyi/llm/llm.py", line 84, in _invoke return self._generate(model, credentials, prompt_messages, model_parameters, tools, stop, stream, user) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/core/model_runtime/model_providers/tongyi/llm/llm.py", line 205, in _generate return self._handle_generate_response(model, credentials, response, prompt_messages) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/core/model_runtime/model_providers/tongyi/llm/llm.py", line 220, in _handle_generate_response raise ServiceUnavailableError(response.message) dashscope.common.error.ServiceUnavailableError: Requests rate limit exceeded, please try again later. During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/app/api/core/rag/index_processor/processor/qa_index_processor.py", line 146, in _format_qa_document response = LLMGenerator.generate_qa_document(tenant_id, document_node.page_content, document_language) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/core/llm_generator/llm_generator.py", line 306, in generate_qa_document response = model_instance.invoke_llm( ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/core/model_manager.py", line 127, in invoke_llm return self._round_robin_invoke( ^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/core/model_manager.py", line 310, in _round_robin_invoke return function(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^ File "/app/api/core/model_runtime/model_providers/__base/large_language_model.py", line 134, in invoke raise self._transform_invoke_error(e) core.model_runtime.errors.invoke.InvokeServerUnavailableError: [tongyi] Server Unavailable Error, Requests rate limit exceeded, please try again later. ``` How can I resolve this issue? ### ✔️ Expected Behavior _No response_ ### ❌ Actual Behavior _No response_
yindo added the 🐞 bug label 2026-02-21 18:20:27 -05:00
yindo closed this issue 2026-02-21 18:20:27 -05:00
yindo commented 2026-02-21 18:20:27 -05:00
Author
Owner
Copy Link
Copy Source

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

To resolve the "Requests rate limit exceeded" error in your self-hosted Dify setup, you can try the following solutions:

  1. Reduce Concurrent Processing: Limit the number of files processed simultaneously or break them into smaller batches to reduce the load on the embedding service.

  2. Implement Retry Logic: Use retry logic with exponential backoff when rate limit errors occur to manage the request flow more effectively. Dify implements exponential backoff by using a backoff factor and retrying the request with increasing delays [1].

  3. Use Multiple API Keys: Consider using multiple API keys to distribute the load across different keys, which can help in managing the rate limits better.

  4. Upgrade Machine Resources: Increase your machine's memory capacity to handle more processes without hitting rate limits.

  5. Use a Different Embedding Model Provider: Consider switching to an embedding model provider that offers higher rate limits to accommodate your processing needs.

  6. Check Rate Limits: Ensure that the rate limit for the Embedding model API key used has not been reached. Refer to the official documentation for details on rate limits.

These steps are based on handling similar rate limit issues in Dify version 0.13.2 and the Tongyi embedding service [2].

To continue talking to Dosu, mention @dosu.

Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other

@dosubot[bot] commented on GitHub (Dec 26, 2024): <!-- Answer --> To resolve the "Requests rate limit exceeded" error in your self-hosted Dify setup, you can try the following solutions: 1. **Reduce Concurrent Processing**: Limit the number of files processed simultaneously or break them into smaller batches to reduce the load on the embedding service. 2. **Implement Retry Logic**: Use retry logic with exponential backoff when rate limit errors occur to manage the request flow more effectively. Dify implements exponential backoff by using a backoff factor and retrying the request with increasing delays <sup>[[1]](https://github.com/langgenius/dify/blob/main/api/core/helper/ssrf_proxy.py)</sup>. 3. **Use Multiple API Keys**: Consider using multiple API keys to distribute the load across different keys, which can help in managing the rate limits better. 4. **Upgrade Machine Resources**: Increase your machine's memory capacity to handle more processes without hitting rate limits. 5. **Use a Different Embedding Model Provider**: Consider switching to an embedding model provider that offers higher rate limits to accommodate your processing needs. 6. **Check Rate Limits**: Ensure that the rate limit for the Embedding model API key used has not been reached. Refer to the [official documentation](https://platform.openai.com/docs/guides/rate-limits) for details on rate limits. These steps are based on handling similar rate limit issues in Dify version 0.13.2 and the Tongyi embedding service <sup>[[2]](https://github.com/langgenius/dify/issues/11694)</sup>. <!-- Dosu Comment Footer --> *To continue talking to [Dosu](https://dosu.dev), mention @dosu.* --- <sup>Help Dosu learn! Give it feedback: [Great Response](https://app.dosu.dev/response-feedback/f83f3929-6744-4e94-a8a9-25688285040b?feedback_type=great_response) | [Irrelevant Answer](https://app.dosu.dev/response-feedback/f83f3929-6744-4e94-a8a9-25688285040b?feedback_type=irrelevant_answer) | [Incorrect Sources](https://app.dosu.dev/response-feedback/f83f3929-6744-4e94-a8a9-25688285040b?feedback_type=incorrect_sources) | [Too Verbose](https://app.dosu.dev/response-feedback/f83f3929-6744-4e94-a8a9-25688285040b?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/f83f3929-6744-4e94-a8a9-25688285040b?feedback_type=hallucination) | [Other](https://app.dosu.dev/response-feedback/f83f3929-6744-4e94-a8a9-25688285040b?feedback_type=other)</sup>
yindo commented 2026-02-21 18:20:28 -05:00
Author
Owner
Copy Link
Copy Source

@yihong0618 commented on GitHub (Dec 26, 2024):

will check today thanks

@yihong0618 commented on GitHub (Dec 26, 2024): will check today thanks
yindo commented 2026-02-21 18:20:28 -05:00
Author
Owner
Copy Link
Copy Source

@gongshaojie12 commented on GitHub (Dec 26, 2024):

  1. I only uploaded one file, and the number of files is not large.
  2. How exactly should the retry logic be implemented?
  3. How should the "Use Multiple API Keys" option be configured?
  4. Currently, the machine resources are quite sufficient. It's processing just one file, and 16GB of memory should be enough, right?
  5. I tried OpenAI's text-embedding-3-large, but the same issue occurred.
  6. Regarding rate limits, I only uploaded one file, which is 27MB in size. This shouldn't trigger the limit, right?

To resolve the "Requests rate limit exceeded" error in your self-hosted Dify setup, you can try the following solutions:

  1. Reduce Concurrent Processing: Limit the number of files processed simultaneously or break them into smaller batches to reduce the load on the embedding service.
  2. Implement Retry Logic: Use retry logic with exponential backoff when rate limit errors occur to manage the request flow more effectively. Dify implements exponential backoff by using a backoff factor and retrying the request with increasing delays [1].
  3. Use Multiple API Keys: Consider using multiple API keys to distribute the load across different keys, which can help in managing the rate limits better.
  4. Upgrade Machine Resources: Increase your machine's memory capacity to handle more processes without hitting rate limits.
  5. Use a Different Embedding Model Provider: Consider switching to an embedding model provider that offers higher rate limits to accommodate your processing needs.
  6. Check Rate Limits: Ensure that the rate limit for the Embedding model API key used has not been reached. Refer to the official documentation for details on rate limits.

These steps are based on handling similar rate limit issues in Dify version 0.13.2 and the Tongyi embedding service [2].

To continue talking to Dosu, mention @dosu.

Help Dosu learn! Give it feedback: Great Response | Irrelevant Answer | Incorrect Sources | Too Verbose | Hallucination | Other

@gongshaojie12 commented on GitHub (Dec 26, 2024): 1. I only uploaded one file, and the number of files is not large. 2. How exactly should the retry logic be implemented? 3. How should the "Use Multiple API Keys" option be configured? 4. Currently, the machine resources are quite sufficient. It's processing just one file, and 16GB of memory should be enough, right? 5. I tried OpenAI's **text-embedding-3-large**, but the same issue occurred. 6. Regarding rate limits, I only uploaded one file, which is 27MB in size. This shouldn't trigger the limit, right? > To resolve the "Requests rate limit exceeded" error in your self-hosted Dify setup, you can try the following solutions: > > 1. **Reduce Concurrent Processing**: Limit the number of files processed simultaneously or break them into smaller batches to reduce the load on the embedding service. > 2. **Implement Retry Logic**: Use retry logic with exponential backoff when rate limit errors occur to manage the request flow more effectively. Dify implements exponential backoff by using a backoff factor and retrying the request with increasing delays [[1]](https://github.com/langgenius/dify/blob/main/api/core/helper/ssrf_proxy.py). > 3. **Use Multiple API Keys**: Consider using multiple API keys to distribute the load across different keys, which can help in managing the rate limits better. > 4. **Upgrade Machine Resources**: Increase your machine's memory capacity to handle more processes without hitting rate limits. > 5. **Use a Different Embedding Model Provider**: Consider switching to an embedding model provider that offers higher rate limits to accommodate your processing needs. > 6. **Check Rate Limits**: Ensure that the rate limit for the Embedding model API key used has not been reached. Refer to the [official documentation](https://platform.openai.com/docs/guides/rate-limits) for details on rate limits. > > These steps are based on handling similar rate limit issues in Dify version 0.13.2 and the Tongyi embedding service [[2]](https://github.com/langgenius/dify/issues/11694). > > _To continue talking to [Dosu](https://dosu.dev), mention @dosu._ > > Help Dosu learn! Give it feedback: [Great Response](https://app.dosu.dev/response-feedback/f83f3929-6744-4e94-a8a9-25688285040b?feedback_type=great_response) | [Irrelevant Answer](https://app.dosu.dev/response-feedback/f83f3929-6744-4e94-a8a9-25688285040b?feedback_type=irrelevant_answer) | [Incorrect Sources](https://app.dosu.dev/response-feedback/f83f3929-6744-4e94-a8a9-25688285040b?feedback_type=incorrect_sources) | [Too Verbose](https://app.dosu.dev/response-feedback/f83f3929-6744-4e94-a8a9-25688285040b?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/f83f3929-6744-4e94-a8a9-25688285040b?feedback_type=hallucination) | [Other](https://app.dosu.dev/response-feedback/f83f3929-6744-4e94-a8a9-25688285040b?feedback_type=other)
yindo commented 2026-02-21 18:20:28 -05:00
Author
Owner
Copy Link
Copy Source

@gongshaojie12 commented on GitHub (Dec 26, 2024):

will check today thanks

Alright, looking forward to the results. Thank you.

@gongshaojie12 commented on GitHub (Dec 26, 2024): > will check today thanks Alright, looking forward to the results. Thank you.
yindo commented 2026-02-21 18:20:28 -05:00
Author
Owner
Copy Link
Copy Source

@AugNSo commented on GitHub (Dec 26, 2024):

According to the log, the issue is not on the embedding side but on the LLM side. Q&A mode is passing your chunked document content to LLM generate Q&A pairs. My guess is that your document has a bit more chunks than the rate limit and triggered your LLM provider's error.

@AugNSo commented on GitHub (Dec 26, 2024): According to the log, the issue is not on the embedding side but on the LLM side. Q&A mode is passing your chunked document content to LLM generate Q&A pairs. My guess is that your document has a bit more chunks than the rate limit and triggered your LLM provider's error.
yindo commented 2026-02-21 18:20:28 -05:00
Author
Owner
Copy Link
Copy Source

@gongshaojie12 commented on GitHub (Dec 27, 2024):

According to the log, the issue is not on the embedding side but on the LLM side. Q&A mode is passing your chunked document content to LLM generate Q&A pairs. My guess is that your document has a bit more chunks than the rate limit and triggered your LLM provider's error.

I uploaded a PDF with only two pages, but the same issue occurred. The PDF is as follows.
mobile-aloha.pdf

@gongshaojie12 commented on GitHub (Dec 27, 2024): > According to the log, the issue is not on the embedding side but on the LLM side. Q&A mode is passing your chunked document content to LLM generate Q&A pairs. My guess is that your document has a bit more chunks than the rate limit and triggered your LLM provider's error. I uploaded a PDF with only two pages, but the same issue occurred. The PDF is as follows. [mobile-aloha.pdf](https://github.com/user-attachments/files/18257826/mobile-aloha.pdf)
yindo commented 2026-02-21 18:20:28 -05:00
Author
Owner
Copy Link
Copy Source

@yihong0618 commented on GitHub (Dec 27, 2024):

According to the log, the issue is not on the embedding side but on the LLM side. Q&A mode is passing your chunked document content to LLM generate Q&A pairs. My guess is that your document has a bit more chunks than the rate limit and triggered your LLM provider's error.

I uploaded a PDF with only two pages, but the same issue occurred. The PDF is as follows. mobile-aloha.pdf

This pdf works fine in my side..

@yihong0618 commented on GitHub (Dec 27, 2024): > > According to the log, the issue is not on the embedding side but on the LLM side. Q&A mode is passing your chunked document content to LLM generate Q&A pairs. My guess is that your document has a bit more chunks than the rate limit and triggered your LLM provider's error. > > I uploaded a PDF with only two pages, but the same issue occurred. The PDF is as follows. [mobile-aloha.pdf](https://github.com/user-attachments/files/18257826/mobile-aloha.pdf) This pdf works fine in my side..
yindo commented 2026-02-21 18:20:28 -05:00
Author
Owner
Copy Link
Copy Source

@gongshaojie12 commented on GitHub (Dec 27, 2024):

That's strange. I only modified a few parameters in the .env and docker-compose.yaml files, as shown below.

.env

UPLOAD_FILE_SIZE_LIMIT=1024
UPLOAD_FILE_BATCH_LIMIT=500
ETL_TYPE=Unstructured
UNSTRUCTURED_API_URL=http://unstructured:8000/general/v0/general

docker-compose.yaml

UPLOAD_FILE_SIZE_LIMIT: ${UPLOAD_FILE_SIZE_LIMIT:-1024}
UPLOAD_FILE_BATCH_LIMIT: ${UPLOAD_FILE_BATCH_LIMIT:-500}
environment:
  NGINX_CLIENT_MAX_BODY_SIZE: 1024M

I haven't made any other changes. @yihong0618

@gongshaojie12 commented on GitHub (Dec 27, 2024): That's strange. I only modified a few parameters in the .env and docker-compose.yaml files, as shown below. **.env** ``` UPLOAD_FILE_SIZE_LIMIT=1024 UPLOAD_FILE_BATCH_LIMIT=500 ETL_TYPE=Unstructured UNSTRUCTURED_API_URL=http://unstructured:8000/general/v0/general ``` **docker-compose.yaml** ``` UPLOAD_FILE_SIZE_LIMIT: ${UPLOAD_FILE_SIZE_LIMIT:-1024} UPLOAD_FILE_BATCH_LIMIT: ${UPLOAD_FILE_BATCH_LIMIT:-500} environment: NGINX_CLIENT_MAX_BODY_SIZE: 1024M ``` I haven't made any other changes. @yihong0618
yindo commented 2026-02-21 18:20:28 -05:00
Author
Owner
Copy Link
Copy Source

@AugNSo commented on GitHub (Dec 27, 2024):

Made the same change to .env and docker-compose.yaml, still cannot replicated your problem with the pdf file provided.

@AugNSo commented on GitHub (Dec 27, 2024): Made the same change to .env and docker-compose.yaml, still cannot replicated your problem with the pdf file provided.
yindo commented 2026-02-21 18:20:28 -05:00
Author
Owner
Copy Link
Copy Source

@gongshaojie12 commented on GitHub (Dec 27, 2024):

That's so strange.

@gongshaojie12 commented on GitHub (Dec 27, 2024): That's so strange.
yindo commented 2026-02-21 18:20:28 -05:00
Author
Owner
Copy Link
Copy Source

@AugNSo commented on GitHub (Dec 27, 2024):

What is your current dify's system model? Can you try changing your dify's system reasoning model to a model with a higher rate limit or a locally deployed one and see whether the problem persists?

@AugNSo commented on GitHub (Dec 27, 2024): What is your current dify's system model? Can you try changing your dify's system reasoning model to a model with a higher rate limit or a locally deployed one and see whether the problem persists?
yindo commented 2026-02-21 18:20:28 -05:00
Author
Owner
Copy Link
Copy Source

@gongshaojie12 commented on GitHub (Dec 27, 2024):

dify's system model:qwen-vl-max。After switching to qwen-max, it was able to process normally, but ultra-long PDF files still fail to process. This should be related to the model's rate limit. Currently, local model deployment is not possible. Can Dify control the indexing speed during the indexing process?

@gongshaojie12 commented on GitHub (Dec 27, 2024): dify's system model:**qwen-vl-max**。After switching to **qwen-max**, it was able to process normally, but ultra-long PDF files still fail to process. This should be related to the model's rate limit. Currently, local model deployment is not possible. Can Dify control the indexing speed during the indexing process?
yindo commented 2026-02-21 18:20:28 -05:00
Author
Owner
Copy Link
Copy Source

@AugNSo commented on GitHub (Dec 29, 2024):

From my experience, you don’t really need qwen-max for task like this, but if you insist, contacting the service provider to increase the rate limit is also an option.
@yihong0618 I think the issue can be closed, not a bug.

@AugNSo commented on GitHub (Dec 29, 2024): From my experience, you don’t really need qwen-max for task like this, but if you insist, contacting the service provider to increase the rate limit is also an option. @yihong0618 I think the issue can be closed, not a bug.
yindo commented 2026-02-21 18:20:28 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Jan 30, 2025):

Hi, @gongshaojie12. I'm Dosu, and I'm helping the Dify team manage their backlog. I'm marking this issue as stale.

Issue Summary

  • You reported a rate limit exceeded error during the "Save and Process" step in Q&A mode when self-hosted using Docker.
  • Solutions suggested included reducing concurrent processing, implementing retry logic, and using multiple API keys.
  • Switching to the qwen-max model resolved the issue for shorter PDFs, indicating a model rate limit issue.
  • It was suggested that the issue might not be a bug and to contact the service provider for a rate limit increase.

Next Steps

  • Please confirm if this issue is still relevant to the latest version of the Dify repository. If so, you can keep the discussion open by commenting here.
  • If there is no further activity, this issue will be automatically closed in 15 days.

Thank you for your understanding and contribution!

@dosubot[bot] commented on GitHub (Jan 30, 2025): Hi, @gongshaojie12. I'm [Dosu](https://dosu.dev), and I'm helping the Dify team manage their backlog. I'm marking this issue as stale. **Issue Summary** - You reported a rate limit exceeded error during the "Save and Process" step in Q&A mode when self-hosted using Docker. - Solutions suggested included reducing concurrent processing, implementing retry logic, and using multiple API keys. - Switching to the **qwen-max** model resolved the issue for shorter PDFs, indicating a model rate limit issue. - It was suggested that the issue might not be a bug and to contact the service provider for a rate limit increase. **Next Steps** - Please confirm if this issue is still relevant to the latest version of the Dify repository. If so, you can keep the discussion open by commenting here. - If there is no further activity, this issue will be automatically closed in 15 days. Thank you for your understanding and contribution!
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#7409
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?