You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.15.3
Cloud or Self Hosted
Self Hosted (Docker)
Steps to reproduce
Configure envs to use external database, redis and storage (S3).
Remove all container's volume
Restart containers
✔️ Expected Behavior
I am hosting Dify on an EC2 instance using Docker Compose and deploying it via a Bitbucket pipeline. In my pipeline, I essentially remove all Dify-related files from the server, redeploy the application, stop the containers, and then start them again.
I've already externalized some environment variables to connect to an external database, S3 storage, and Redis. However, after each redeploy, when I try to perform a retrieval test through the front end, I encounter a "GraphQL schema not found" error. The issue resolves if I deactivate and reactivate the document, but this isn't ideal.
My question is: how can I make this process more reliable so that, even after a redeploy, the system continues to work with the existing data without issues? What might I be overlooking?
❌ Actual Behavior
Some graphql is not created when containers are restarted
Query was not successful! Unexpected status code: 422, with response body: {'error': [{'message': 'no graphql provider present, this is most likely because no schema is present. Import a schema first!'}]}.; Query was not successful! Unexpected status code: 422, with response body: {'error': [{'message': 'no graphql provider present, this is most likely because no schema is present. Import a schema first!'}]}.
The text was updated successfully, but these errors were encountered:
I found a similar unsolved discussion titled "Self hosting problem after rebooting machine" on the Dify GitHub repository. You can view it here[1].
Regarding your issue, it seems that the GraphQL schema is not being retained across container restarts. To address this, ensure that your Docker volumes for the database and other services are correctly configured to persist data. Specifically, mark the database volume as external in your docker-compose.yaml file to prevent it from being removed during docker compose down operations [2].
Additionally, verify that your environment variables are correctly set to point to the external services and that these services are accessible and properly configured. This setup should help maintain the GraphQL schema and other data across redeployments.
Self Checks
Dify version
0.15.3
Cloud or Self Hosted
Self Hosted (Docker)
Steps to reproduce
✔️ Expected Behavior
I am hosting Dify on an EC2 instance using Docker Compose and deploying it via a Bitbucket pipeline. In my pipeline, I essentially remove all Dify-related files from the server, redeploy the application, stop the containers, and then start them again.
I've already externalized some environment variables to connect to an external database, S3 storage, and Redis. However, after each redeploy, when I try to perform a retrieval test through the front end, I encounter a "GraphQL schema not found" error. The issue resolves if I deactivate and reactivate the document, but this isn't ideal.
My question is: how can I make this process more reliable so that, even after a redeploy, the system continues to work with the existing data without issues? What might I be overlooking?
❌ Actual Behavior
Some graphql is not created when containers are restarted
Query was not successful! Unexpected status code: 422, with response body: {'error': [{'message': 'no graphql provider present, this is most likely because no schema is present. Import a schema first!'}]}.; Query was not successful! Unexpected status code: 422, with response body: {'error': [{'message': 'no graphql provider present, this is most likely because no schema is present. Import a schema first!'}]}.
The text was updated successfully, but these errors were encountered: