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

I call app B with my app A. App B has the correct return within a few tens of seconds, but app A returns with an error after only 4 seconds of calling. #6081

New Issue
Closed
opened 2026-02-21 18:13:59 -05:00 by yindo · 5 comments
yindo commented 2026-02-21 18:13:59 -05:00
Owner
Copy Link
Copy Source

Originally created by @Yi-Lyu on GitHub (Oct 14, 2024).

Originally assigned to: @laipz8200 on GitHub.

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.10.0-beta2

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

I call app B with my app A. App B has the correct return within a few tens of seconds, but app A returns with an error after only 4 seconds of calling.

I can't turn on the setting SSRF_DEFAULT_MAX_RETRIES because once SSRF_DEFAULT_MAX_RETRIES is set to a non-zero positive value, I get my previous situation again, refer to https://github.com/langgenius/dify/issues/9312

Here is a picture for you to understand

image image

✔️ Expected Behavior

No response

❌ Actual Behavior

No response

Originally created by @Yi-Lyu on GitHub (Oct 14, 2024). Originally assigned to: @laipz8200 on GitHub. ### 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.10.0-beta2 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce I call app B with my app A. App B has the correct return within a few tens of seconds, but app A returns with an error after only 4 seconds of calling. I can't turn on the setting SSRF_DEFAULT_MAX_RETRIES because once SSRF_DEFAULT_MAX_RETRIES is set to a non-zero positive value, I get my previous situation again, refer to https://github.com/langgenius/dify/issues/9312 Here is a picture for you to understand <img width="2227" alt="image" src="https://github.com/user-attachments/assets/67fefe6a-44e5-4578-ad11-d9b8b4e7925a"> <img width="2877" alt="image" src="https://github.com/user-attachments/assets/d2907cc7-6f26-483a-a0af-cedaa6efcc93"> ### ✔️ Expected Behavior _No response_ ### ❌ Actual Behavior _No response_
yindo added the 🐞 bug label 2026-02-21 18:13:59 -05:00
yindo closed this issue 2026-02-21 18:13:59 -05:00
yindo commented 2026-02-21 18:14:00 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Oct 14, 2024):

The issue you're experiencing with App A returning an error after 4 seconds when calling App B might be related to the HTTP request timeout settings or retry logic in Dify version 0.10.0-beta2.

Here are a few things to consider:

  1. Timeout Settings: Check if the default timeout settings are causing the request to fail prematurely. The default connect timeout is 10 seconds, read timeout is 60 seconds, and write timeout is 20 seconds [1].

  2. Retry Logic: The SSRF_DEFAULT_MAX_RETRIES setting controls the number of retry attempts for HTTP requests. If this is set to a non-zero value, it might be causing issues due to multiple retries [2].

  3. Concurrency Management: Ensure that the concurrency settings, such as APP_MAX_ACTIVE_REQUESTS, are configured correctly to handle the load without causing premature failures [3].

You might want to adjust these settings to see if it resolves the issue. If the problem persists, reviewing the logs for specific error messages related to timeouts or retries could provide more insights.

To continue talking to Dosu, mention @dosu.

@dosubot[bot] commented on GitHub (Oct 14, 2024): <!-- Answer --> The issue you're experiencing with App A returning an error after 4 seconds when calling App B might be related to the HTTP request timeout settings or retry logic in Dify version 0.10.0-beta2. Here are a few things to consider: 1. **Timeout Settings**: Check if the default timeout settings are causing the request to fail prematurely. The default connect timeout is 10 seconds, read timeout is 60 seconds, and write timeout is 20 seconds <sup>[[1]](https://github.com/langgenius/dify/blob/main/api/.env.example)</sup>. 2. **Retry Logic**: The `SSRF_DEFAULT_MAX_RETRIES` setting controls the number of retry attempts for HTTP requests. If this is set to a non-zero value, it might be causing issues due to multiple retries <sup>[[2]](https://github.com/langgenius/dify/blob/main/api/core/helper/ssrf_proxy.py)</sup>. 3. **Concurrency Management**: Ensure that the concurrency settings, such as `APP_MAX_ACTIVE_REQUESTS`, are configured correctly to handle the load without causing premature failures <sup>[[3]](https://github.com/langgenius/dify/blob/main/docker-legacy/docker-compose.yaml)</sup>. You might want to adjust these settings to see if it resolves the issue. If the problem persists, reviewing the logs for specific error messages related to timeouts or retries could provide more insights. <!-- Dosu Comment Footer --> *To continue talking to [Dosu](https://dosu.dev), mention @dosu.*
yindo commented 2026-02-21 18:14:00 -05:00
Author
Owner
Copy Link
Copy Source

@Yi-Lyu commented on GitHub (Oct 14, 2024):

The issue you're experiencing with App A returning an error after 4 seconds when calling App B might be related to the HTTP request timeout settings or retry logic in Dify version 0.10.0-beta2.您在调用应用程序 B 时，应用程序 A 在 4 秒后返回错误的问题可能与 Dify 版本 0.10.0-beta2 中的 HTTP 请求超时设置或重试逻辑有关。

Here are a few things to consider:这里有几个需要考虑的事项：

  1. Timeout Settings: Check if the default timeout settings are causing the request to fail prematurely. The default connect timeout is 10 seconds, read timeout is 60 seconds, and write timeout is 20 seconds [1].超时设置：检查默认的超时设置是否导致请求过早失败。默认连接超时为 10 秒，读取超时为 60 秒，写入超时为 20 秒 [1]。
  2. Retry Logic: The SSRF_DEFAULT_MAX_RETRIES setting controls the number of retry attempts for HTTP requests. If this is set to a non-zero value, it might be causing issues due to multiple retries [2].重试逻辑：SSRF_DEFAULT_MAX_RETRIES 设置控制 HTTP 请求的重试次数。如果此值设置为非零值，可能会由于多次重试而导致问题 [2]。
  3. Concurrency Management: Ensure that the concurrency settings, such as APP_MAX_ACTIVE_REQUESTS, are configured correctly to handle the load without causing premature failures [3].并发管理：确保并发设置，例如 APP_MAX_ACTIVE_REQUESTS，已正确配置以处理负载，而不会导致过早失败 [3]。

You might want to adjust these settings to see if it resolves the issue. If the problem persists, reviewing the logs for specific error messages related to timeouts or retries could provide more insights.您可能想调整这些设置，以查看是否能解决问题。如果问题仍然存在，查看与超时或重试相关的特定错误消息的日志可能会提供更多见解。

To continue talking to Dosu, mention @dosu.要继续与 Dosu 交谈，请提及。

Regarding your suggestion #1, I've set great values before, as shown.
image

now my .env set APP_MAX_ACTIVE_REQUESTS=0

@Yi-Lyu commented on GitHub (Oct 14, 2024): > The issue you're experiencing with App A returning an error after 4 seconds when calling App B might be related to the HTTP request timeout settings or retry logic in Dify version 0.10.0-beta2.您在调用应用程序 B 时，应用程序 A 在 4 秒后返回错误的问题可能与 Dify 版本 0.10.0-beta2 中的 HTTP 请求超时设置或重试逻辑有关。 > > Here are a few things to consider:这里有几个需要考虑的事项： > > 1. **Timeout Settings**: Check if the default timeout settings are causing the request to fail prematurely. The default connect timeout is 10 seconds, read timeout is 60 seconds, and write timeout is 20 seconds [[1]](https://github.com/langgenius/dify/blob/main/api/.env.example).**超时设置**：检查默认的超时设置是否导致请求过早失败。默认连接超时为 10 秒，读取超时为 60 秒，写入超时为 20 秒 [[1]](https://github.com/langgenius/dify/blob/main/api/.env.example)。 > 2. **Retry Logic**: The `SSRF_DEFAULT_MAX_RETRIES` setting controls the number of retry attempts for HTTP requests. If this is set to a non-zero value, it might be causing issues due to multiple retries [[2]](https://github.com/langgenius/dify/blob/main/api/core/helper/ssrf_proxy.py).**重试逻辑**：`SSRF_DEFAULT_MAX_RETRIES` 设置控制 HTTP 请求的重试次数。如果此值设置为非零值，可能会由于多次重试而导致问题 [[2]](https://github.com/langgenius/dify/blob/main/api/core/helper/ssrf_proxy.py)。 > 3. **Concurrency Management**: Ensure that the concurrency settings, such as `APP_MAX_ACTIVE_REQUESTS`, are configured correctly to handle the load without causing premature failures [[3]](https://github.com/langgenius/dify/blob/main/docker-legacy/docker-compose.yaml).**并发管理**：确保并发设置，例如 `APP_MAX_ACTIVE_REQUESTS`，已正确配置以处理负载，而不会导致过早失败 [[3]](https://github.com/langgenius/dify/blob/main/docker-legacy/docker-compose.yaml)。 > > You might want to adjust these settings to see if it resolves the issue. If the problem persists, reviewing the logs for specific error messages related to timeouts or retries could provide more insights.您可能想调整这些设置，以查看是否能解决问题。如果问题仍然存在，查看与超时或重试相关的特定错误消息的日志可能会提供更多见解。 > > _To continue talking to [Dosu](https://dosu.dev), mention @dosu.要继续与 [Dosu](https://dosu.dev) 交谈，请提及。_ Regarding your suggestion #1, I've set great values before, as shown. <img width="2644" alt="image" src="https://github.com/user-attachments/assets/979853ee-974a-452d-8b3f-bf9cc7a69883"> now my .env set APP_MAX_ACTIVE_REQUESTS=0
yindo commented 2026-02-21 18:14:00 -05:00
Author
Owner
Copy Link
Copy Source

@Yi-Lyu commented on GitHub (Oct 14, 2024):

docker-api-1 logs

image
@Yi-Lyu commented on GitHub (Oct 14, 2024): docker-api-1 logs <img width="1519" alt="image" src="https://github.com/user-attachments/assets/30b82b3b-6dfd-499a-a3dc-924f3f4449aa">
yindo commented 2026-02-21 18:14:00 -05:00
Author
Owner
Copy Link
Copy Source

@yeelousun commented on GitHub (Oct 28, 2024):

I encountered a similar issue, and I believe it was related to the proxy settings. The proxy request was prematurely canceled, and although the HTTP request continued to execute, it couldn't return correctly.

So, I decided to disable the proxy settings by commenting out the SSRF_PROXY_HTTP_URL and SSRF_PROXY_HTTPS_URL lines in the docker-compose.yaml file, which resolved the issue.

@yeelousun commented on GitHub (Oct 28, 2024): I encountered a similar issue, and I believe it was related to the proxy settings. The proxy request was prematurely canceled, and although the HTTP request continued to execute, it couldn't return correctly. So, I decided to disable the proxy settings by commenting out the SSRF_PROXY_HTTP_URL and SSRF_PROXY_HTTPS_URL lines in the docker-compose.yaml file, which resolved the issue.
yindo commented 2026-02-21 18:14:00 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Nov 29, 2024):

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

Issue Summary

  • You reported an error with app A when calling app B, despite app B returning the correct response.
  • Adjusting SSRF_DEFAULT_MAX_RETRIES did not resolve the issue and led to another problem.
  • I suggested checking timeout settings, retry logic, and concurrency management.
  • Yeelousun resolved a similar issue by disabling proxy settings in the docker-compose.yaml file, which appears to have resolved your issue as well.

Next Steps

  • Please confirm if this issue is still relevant to the latest version of the Dify repository. If it is, you can keep the discussion open by commenting on this issue.
  • Otherwise, this issue will be automatically closed in 15 days.

Thank you for your understanding and contribution!

@dosubot[bot] commented on GitHub (Nov 29, 2024): Hi, @Yi-Lyu. 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 an error with app A when calling app B, despite app B returning the correct response. - Adjusting `SSRF_DEFAULT_MAX_RETRIES` did not resolve the issue and led to another problem. - I suggested checking timeout settings, retry logic, and concurrency management. - Yeelousun resolved a similar issue by disabling proxy settings in the `docker-compose.yaml` file, which appears to have resolved your issue as well. **Next Steps** - Please confirm if this issue is still relevant to the latest version of the Dify repository. If it is, you can keep the discussion open by commenting on this issue. - Otherwise, 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#6081
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?