Dify Plugin fails to call app chatflow

[RobertDiep]

Self Checks

• [x] This is only for bug report, if you would like to ask a question, please head to Discussions.
• [x] I have searched for existing issues search for existing issues, including closed ones.
• [x] I confirm that I am using English to submit this report (我已阅读并同意 Language Policy).
• [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

[dosubot[bot]]

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}

[hxt365]

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

[RobertDiep]

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.