Dify Plugin fails to call app chatflow #13018

Closed
opened 2026-02-21 19:10:10 -05:00 by yindo · 3 comments
Owner

Originally created by @RobertDiep on GitHub (Apr 16, 2025).

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

1.2.0

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

I am writing a Slack bot plugin that handles multiple channels and workflows on 1 endpoint. I want to store the conversation ID in Slack's metadata attribute. However, after calling the conversations_replies() method to get the conversation id back, the ChatFlow fails with the following exception:

Exception: invocation exited without response

At first, I figured it was due to urllib being called in a thread, so I switched to httpx but observed the same behaviour.

The full code can be found here: https://github.com/RobertDiep/dify-slackbot/blob/main/endpoints/nwslackbot.py#L72

The bot works correctly outside of a thread, so I suspect the HTTP call deadlocks something

✔️ Expected Behavior

Correctly calling the chatflow when having performed an HTTP request beforehand

Actual Behavior

After calling Slack's conversations_replies() method to get the conversation id back, the ChatFlow fails with the following exception:

Exception: invocation exited without response
Originally created by @RobertDiep on GitHub (Apr 16, 2025). ### 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 1.2.0 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce I am writing a Slack bot plugin that handles multiple channels and workflows on 1 endpoint. I want to store the conversation ID in Slack's metadata attribute. However, after calling the conversations_replies() method to get the conversation id back, the ChatFlow fails with the following exception: Exception: invocation exited without response At first, I figured it was due to urllib being called in a thread, so I switched to httpx but observed the same behaviour. The full code can be found here: https://github.com/RobertDiep/dify-slackbot/blob/main/endpoints/nwslackbot.py#L72 The bot works correctly outside of a thread, so I suspect the HTTP call deadlocks something ### ✔️ Expected Behavior Correctly calling the chatflow when having performed an HTTP request beforehand ### ❌ Actual Behavior After calling Slack's conversations_replies() method to get the conversation id back, the ChatFlow fails with the following exception: Exception: invocation exited without response
yindo closed this issue 2026-02-21 19:10:10 -05:00
Author
Owner

@dosubot[bot] commented on GitHub (Apr 16, 2025):

Hello @RobertDiep! I'm Dosu, your friendly bot here to help you solve bugs, answer questions, and support you as a contributor. I'm here to assist you while you wait for a human maintainer. Let's tackle that issue together!

The issue you're encountering with the Dify plugin failing to call the app chatflow after making an HTTP request in a threaded environment might be related to the threading model and how HTTP requests are handled in Dify's self-hosted environment.

Here are some configurations and settings that could affect threading and HTTP request handling in Dify:

  1. Threading Configuration:

    • MAX_SUBMIT_COUNT: This setting specifies the maximum number of submitted threads in a ThreadPool for parallel node execution. The default is 100, which might need adjustment based on your workload.
  2. HTTP Request Handling:

    • Ensure that your HTTP request timeouts are configured appropriately. The default maximum connection timeout is 300 seconds, and the read and write timeouts are 600 seconds each. These can be adjusted if necessary.
    • Check the HTTP_REQUEST_NODE_SSL_VERIFY setting, which enables or disables SSL verification for HTTP requests. The default is True, but you might want to disable it for testing purposes to see if it affects the behavior.
  3. Gevent Workers:

    • The number of server workers for the API service is determined by SERVER_WORKER_AMOUNT, which is calculated as number of CPU cores x 2 + 1. This can be configured in the Docker environment and might need adjustment to handle concurrent requests better.

Given that the bot works correctly outside of threading, it suggests that the threading model or the way HTTP requests are managed in threads might be causing the issue. You might want to experiment with these configurations to see if they resolve the deadlock or blocking behavior you're experiencing [1][2][3][4].

To continue talking to Dosu, mention @dosu.


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

@dosubot[bot] commented on GitHub (Apr 16, 2025): <!-- Greeting --> Hello @RobertDiep! I'm [Dosu](https://dosu.dev), your friendly bot here to help you solve bugs, answer questions, and support you as a contributor. I'm here to assist you while you wait for a human maintainer. Let's tackle that issue together! <!-- Answer --> The issue you're encountering with the Dify plugin failing to call the app chatflow after making an HTTP request in a threaded environment might be related to the threading model and how HTTP requests are handled in Dify's self-hosted environment. Here are some configurations and settings that could affect threading and HTTP request handling in Dify: 1. **Threading Configuration**: - `MAX_SUBMIT_COUNT`: This setting specifies the maximum number of submitted threads in a ThreadPool for parallel node execution. The default is 100, which might need adjustment based on your workload. 2. **HTTP Request Handling**: - Ensure that your HTTP request timeouts are configured appropriately. The default maximum connection timeout is 300 seconds, and the read and write timeouts are 600 seconds each. These can be adjusted if necessary. - Check the `HTTP_REQUEST_NODE_SSL_VERIFY` setting, which enables or disables SSL verification for HTTP requests. The default is True, but you might want to disable it for testing purposes to see if it affects the behavior. 3. **Gevent Workers**: - The number of server workers for the API service is determined by `SERVER_WORKER_AMOUNT`, which is calculated as `number of CPU cores x 2 + 1`. This can be configured in the Docker environment and might need adjustment to handle concurrent requests better. Given that the bot works correctly outside of threading, it suggests that the threading model or the way HTTP requests are managed in threads might be causing the issue. You might want to experiment with these configurations to see if they resolve the deadlock or blocking behavior you're experiencing <sup>[[1]](https://github.com/langgenius/dify/blob/main/api/configs/feature/__init__.py)</sup><sup>[[2]](https://github.com/langgenius/dify-docs/blob/main/jp/getting-started/install-self-hosted/environments.md)</sup><sup>[[3]](https://github.com/langgenius/dify-docs/blob/main/zh_CN/getting-started/install-self-hosted/environments.md)</sup><sup>[[4]](https://github.com/langgenius/dify/blob/main/api/.env.example)</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/823119c4-7930-48f2-bf7d-cce22ee085f2?feedback_type=great_response) | [Irrelevant Answer](https://app.dosu.dev/response-feedback/823119c4-7930-48f2-bf7d-cce22ee085f2?feedback_type=irrelevant_answer) | [Incorrect Sources](https://app.dosu.dev/response-feedback/823119c4-7930-48f2-bf7d-cce22ee085f2?feedback_type=incorrect_sources) | [Too Verbose](https://app.dosu.dev/response-feedback/823119c4-7930-48f2-bf7d-cce22ee085f2?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/823119c4-7930-48f2-bf7d-cce22ee085f2?feedback_type=hallucination) | [Bug Report](https://app.dosu.dev/response-feedback/823119c4-7930-48f2-bf7d-cce22ee085f2?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/823119c4-7930-48f2-bf7d-cce22ee085f2?feedback_type=other)</sup>
Author
Owner

@hxt365 commented on GitHub (Jul 3, 2025):

@RobertDiep hi, did you find the root cause and fix it?

@hxt365 commented on GitHub (Jul 3, 2025): @RobertDiep hi, did you find the root cause and fix it?
Author
Owner

@RobertDiep commented on GitHub (Jul 3, 2025):

Unfortunately not, I moved away from using Bolt and implemented the request handling myself which resolved this issue. My guess is there's some threading issue somewhere when using both Bolt and the Dify SDK.

@RobertDiep commented on GitHub (Jul 3, 2025): Unfortunately not, I moved away from using Bolt and implemented the request handling myself which resolved this issue. My guess is there's some threading issue somewhere when using both Bolt and the Dify SDK.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#13018