Issue with Missing Features in Chatbot Workflow Deployment on AWS EC2 Linux Docker

[yyipkei123]

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] 请务必使用英文提交 Issue，否则会被关闭。谢谢！:）
• [X] Please do not modify this template :) and fill in all the required fields.

Dify version

0.6.13

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

I tried to deploy the same chatbot workflow to my own AWS cloud version using Docker, but the follow-up action and title summarization features are missing after deploying to AWS EC2 Linux Docker hosted Dify. I confirmed that I used the same version of Dify, but I'm not sure why there is a difference in the cloud version.

✔️ Expected Behavior

Should be able to display the follow-up action and summarize the chat title.

❌ Actual Behavior

Missing the follow-up action and chat title

[dosubot[bot]]

@yyipkei123 Hello! I'm here to help you with any bugs, questions, or contributions you may have for the project. Let's work together to resolve the issue you're facing.

The difference in features between your local and AWS deployments of your chatbot workflow using Dify version 0.6.13 on Docker could be due to differences in the configuration settings in the .env file or the docker-compose.yaml file.

To ensure consistency, you should:

1. Check the .env file: Make sure that the environment variables in the .env file are correctly set and consistent between your local and AWS deployments. You can refer to the comments in the .env.example file for guidance.

2. Review the docker-compose.yaml file: Ensure that the docker-compose.yaml file is correctly configured for both environments. This includes checking image versions, port mappings, and volume mounts.

Additionally, if you are integrating local models deployed with Ollama, ensure that the Ollama service is accessible from the Docker container. For example, if you encounter connection errors, you may need to expose the Ollama service to the network by using the appropriate host address, such as host.docker.internal instead of localhost ^[1][2].

Also, ensure that the LLM provider key is set correctly, as it is necessary for the follow-up action buttons and chat title summarization features to work properly ^[3].

By ensuring that these configurations are aligned and addressing any network accessibility issues, you can mitigate the differences in features between your local and AWS deployments.

To continue talking to Dosu, mention @dosu.

[yyipkei123]

I suspect the problem may be related to network or SSL issues. Neither of my local environments uses SSL. Can you provide any insights that might help me pinpoint the root cause?

[dosubot[bot]]

The issue might indeed be related to network or SSL configurations. Here are some insights to help you pinpoint the root cause:

1. Network Requests and SSL Certificates:

   • API Service Binding:
     • Ensure DIFY_BIND_ADDRESS is set to 0.0.0.0 to allow access from all addresses.
     • Verify DIFY_PORT is correctly set (default is 5001).
   • Proxy Configuration:
     • If you use a proxy, set HTTP_PROXY and HTTPS_PROXY environment variables appropriately.

2. SSL Configuration:

   • Redis SSL:
     • Set REDIS_USE_SSL to true if you are using SSL for Redis.
   • Celery SSL:
     • Set BROKER_USE_SSL to true if you are using SSL for Celery broker.
   • Milvus SSL:
     • Set MILVUS_SECURE to true if you are using SSL for Milvus.

3. General Best Practices for AWS EC2:

   • Ensure your security groups allow traffic on the necessary ports (e.g., 5001 for the API service).
   • Use an Elastic Load Balancer (ELB) for SSL termination if you are not handling SSL within the Docker containers.

4. Environment Variables:

   • Double-check that all necessary environment variables are set correctly in your .env file, especially those related to network and SSL configurations.

By ensuring these configurations are correctly set, you can address potential network or SSL issues that might be causing the missing features in your AWS deployment ^[1][2][3].

To continue talking to Dosu, mention @dosu.

[crazywoola]

@guchenhe

[yyipkei123]

Could you please provide an update on this? I'm confident the configuration remains the same since I deployed it using Docker following the steps provided in the documentation. Is there any special network setting I need to add in the cloud or elsewhere to restore functionality? Thanks!

[guchenhe]

hey - in your browser's developer view, can you check the status for the related network requests under the networks tab? for example, there should be a request made to conversations/<conversation_id>/name that renames the conversation.