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

API Returns Empty Data for Conversations and Messages Endpoints #7549

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

Originally created by @EvelynBai on GitHub (Jan 6, 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

0.14.1

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

I am trying to get the latest conversation id and messages via API:

  1. Fetch Conversations:
    curl -X GET 'http://10.6.43.33/v1/conversations?user=test&limit=20' --header 'Authorization: Bearer {my-api-key}'
  2. Fetch Messages:
    curl -X GET 'http://10.6.43.33/v1/messages?user=test&conversation_id=’ --header 'Authorization: Bearer {my-api-key}'
  3. However, both API calls return an empty data field:
    {"limit": 20, "has_more": false, "data": []}

Previous Troubleshooting:
I encountered a database error indicating permission issues during sudo docker compose up -d:
db-1 | mkdir: can't create directory '/var/lib/postgresql/data/pgdata': Permission denied db-1 exited with code 1
To address this, I attempted to change directory permissions:
sudo chmod -R 700 ./volumes/db/data under the docker yaml file directory.
However, the problem persisted. Consequently, I modified the docker-compose.yaml file to adjust the DB volumes:
截屏2025-01-07 上午10 41 59
Could the recent modifications to the DB volumes in docker-compose.yaml be causing the API to return empty data?

✔️ Expected Behavior

As in the document:
{ "limit": 20, "has_more": false, "data": [ { "id": "a076a87f-31e5-48dc-b452-0061adbbc922", "conversation_id": "cd78daf6-f9e4-4463-9ff2-54257230a0ce", "inputs": { "name": "dify" }, "query": "iphone 13 pro", "answer": "The iPhone 13 Pro, released on September 24, 2021, features a 6.1-inch display with a resolution of 1170 x 2532. It is equipped with a Hexa-core (2x3.23 GHz Avalanche + 4x1.82 GHz Blizzard) processor, 6 GB of RAM, and offers storage options of 128 GB, 256 GB, 512 GB, and 1 TB. The camera is 12 MP, the battery capacity is 3095 mAh, and it runs on iOS 15.", "message_files": [], "feedback": null, "retriever_resources": [ { "position": 1, "dataset_id": "101b4c97-fc2e-463c-90b1-5261a4cdcafb", "dataset_name": "iPhone", "document_id": "8dd1ad74-0b5f-4175-b735-7d98bbbb4e00", "document_name": "iPhone List", "segment_id": "ed599c7f-2766-4294-9d1d-e5235a61270a", "score": 0.98457545, "content": "\"Model\",\"Release Date\",\"Display Size\",\"Resolution\",\"Processor\",\"RAM\",\"Storage\",\"Camera\",\"Battery\",\"Operating System\"\n\"iPhone 13 Pro Max\",\"September 24, 2021\",\"6.7 inch\",\"1284 x 2778\",\"Hexa-core (2x3.23 GHz Avalanche + 4x1.82 GHz Blizzard)\",\"6 GB\",\"128, 256, 512 GB, 1TB\",\"12 MP\",\"4352 mAh\",\"iOS 15\"" } ], "agent_thoughts": [], "created_at": 1705569239 } ] }

❌ Actual Behavior

{"limit": 20, "has_more": false, "data": []}

Originally created by @EvelynBai on GitHub (Jan 6, 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 0.14.1 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce I am trying to get the latest conversation id and messages via API: 1. Fetch Conversations: `curl -X GET 'http://10.6.43.33/v1/conversations?user=test&limit=20' --header 'Authorization: Bearer {my-api-key}'` 2. Fetch Messages: `curl -X GET 'http://10.6.43.33/v1/messages?user=test&conversation_id=’ --header 'Authorization: Bearer {my-api-key}'` 3. However, both API calls return an empty data field: `{"limit": 20, "has_more": false, "data": []}` **Previous Troubleshooting:** I encountered a database error indicating permission issues during `sudo docker compose up -d`: `db-1 | mkdir: can't create directory '/var/lib/postgresql/data/pgdata': Permission denied db-1 exited with code 1` To address this, I attempted to change directory permissions: `sudo chmod -R 700 ./volumes/db/data` under the docker yaml file directory. However, the problem persisted. Consequently, I modified the docker-compose.yaml file to adjust the DB volumes: <img width="640" alt="截屏2025-01-07 上午10 41 59" src="https://github.com/user-attachments/assets/d50e3fe5-e104-42c5-88f6-bb9c03917466" /> Could the recent modifications to the DB volumes in docker-compose.yaml be causing the API to return empty data? ### ✔️ Expected Behavior As in the document: `{ "limit": 20, "has_more": false, "data": [ { "id": "a076a87f-31e5-48dc-b452-0061adbbc922", "conversation_id": "cd78daf6-f9e4-4463-9ff2-54257230a0ce", "inputs": { "name": "dify" }, "query": "iphone 13 pro", "answer": "The iPhone 13 Pro, released on September 24, 2021, features a 6.1-inch display with a resolution of 1170 x 2532. It is equipped with a Hexa-core (2x3.23 GHz Avalanche + 4x1.82 GHz Blizzard) processor, 6 GB of RAM, and offers storage options of 128 GB, 256 GB, 512 GB, and 1 TB. The camera is 12 MP, the battery capacity is 3095 mAh, and it runs on iOS 15.", "message_files": [], "feedback": null, "retriever_resources": [ { "position": 1, "dataset_id": "101b4c97-fc2e-463c-90b1-5261a4cdcafb", "dataset_name": "iPhone", "document_id": "8dd1ad74-0b5f-4175-b735-7d98bbbb4e00", "document_name": "iPhone List", "segment_id": "ed599c7f-2766-4294-9d1d-e5235a61270a", "score": 0.98457545, "content": "\"Model\",\"Release Date\",\"Display Size\",\"Resolution\",\"Processor\",\"RAM\",\"Storage\",\"Camera\",\"Battery\",\"Operating System\"\n\"iPhone 13 Pro Max\",\"September 24, 2021\",\"6.7 inch\",\"1284 x 2778\",\"Hexa-core (2x3.23 GHz Avalanche + 4x1.82 GHz Blizzard)\",\"6 GB\",\"128, 256, 512 GB, 1TB\",\"12 MP\",\"4352 mAh\",\"iOS 15\"" } ], "agent_thoughts": [], "created_at": 1705569239 } ] }` ### ❌ Actual Behavior `{"limit": 20, "has_more": false, "data": []}`
yindo added the 🐞 buggood first issue labels 2026-02-21 18:21:09 -05:00
yindo closed this issue 2026-02-21 18:21:09 -05:00
yindo commented 2026-02-21 18:21:10 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Jan 6, 2025):

Hey there, @EvelynBai! 👋 I'm here to help you with bug fixes, questions, and even becoming a contributor.

The issue of receiving empty data from the Dify API endpoints for conversations and messages might be related to the database permission error you encountered. Here are some steps to troubleshoot and resolve the issue:

  1. Database Permissions: Ensure that the PostgreSQL data directory has the correct permissions. The directory should be owned by the postgres user and group. You can set the ownership with the following command:

    sudo chown -R 999:999 ./volumes/db/data

    The user ID 999 is typically used for the postgres user in Docker containers.

  2. Docker Volumes Configuration: Verify that the Docker volumes are correctly configured in your docker-compose.yaml file. The volume for PostgreSQL should be mapped correctly to ensure data persistence:

    volumes:
  - ./volumes/db/data:/var/lib/postgresql/data

  3. Database Initialization: If the database was not initialized correctly due to permission issues, you might need to remove the existing data directory and allow Docker to reinitialize it:

    sudo rm -rf ./volumes/db/data
sudo docker compose up -d

  4. Check Logs: Review the logs for the PostgreSQL container to ensure that it is starting correctly without errors. You can view the logs using:

    sudo docker logs <db-container-name>

  5. API Key and Authorization: Double-check that the API key is valid and correctly formatted in the Authorization header as Bearer {my-api-key}.

  6. Data Availability: Ensure that there is data available in the database for the API to return. If the database is empty, the API will naturally return an empty data array.

By following these steps, you should be able to resolve the issue with empty data responses from the API. If the problem persists, further investigation into the database setup and API configuration may be necessary.

To continue talking to Dosu, mention @dosu.

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

@dosubot[bot] commented on GitHub (Jan 6, 2025): <!-- Greeting --> Hey there, @EvelynBai! 👋 I'm here to help you with bug fixes, questions, and even becoming a contributor. <!-- Answer --> The issue of receiving empty data from the Dify API endpoints for conversations and messages might be related to the database permission error you encountered. Here are some steps to troubleshoot and resolve the issue: 1. **Database Permissions**: Ensure that the PostgreSQL data directory has the correct permissions. The directory should be owned by the `postgres` user and group. You can set the ownership with the following command: ```bash sudo chown -R 999:999 ./volumes/db/data ``` The user ID `999` is typically used for the `postgres` user in Docker containers. 2. **Docker Volumes Configuration**: Verify that the Docker volumes are correctly configured in your `docker-compose.yaml` file. The volume for PostgreSQL should be mapped correctly to ensure data persistence: ```yaml volumes: - ./volumes/db/data:/var/lib/postgresql/data ``` 3. **Database Initialization**: If the database was not initialized correctly due to permission issues, you might need to remove the existing data directory and allow Docker to reinitialize it: ```bash sudo rm -rf ./volumes/db/data sudo docker compose up -d ``` 4. **Check Logs**: Review the logs for the PostgreSQL container to ensure that it is starting correctly without errors. You can view the logs using: ```bash sudo docker logs <db-container-name> ``` 5. **API Key and Authorization**: Double-check that the API key is valid and correctly formatted in the Authorization header as `Bearer {my-api-key}`. 6. **Data Availability**: Ensure that there is data available in the database for the API to return. If the database is empty, the API will naturally return an empty data array. By following these steps, you should be able to resolve the issue with empty data responses from the API. If the problem persists, further investigation into the database setup and API configuration may be necessary. <!-- 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/12857a7d-89a6-4e0d-a3e7-6c762e5167e2?feedback_type=great_response) | [Irrelevant Answer](https://app.dosu.dev/response-feedback/12857a7d-89a6-4e0d-a3e7-6c762e5167e2?feedback_type=irrelevant_answer) | [Incorrect Sources](https://app.dosu.dev/response-feedback/12857a7d-89a6-4e0d-a3e7-6c762e5167e2?feedback_type=incorrect_sources) | [Too Verbose](https://app.dosu.dev/response-feedback/12857a7d-89a6-4e0d-a3e7-6c762e5167e2?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/12857a7d-89a6-4e0d-a3e7-6c762e5167e2?feedback_type=hallucination) | [Other](https://app.dosu.dev/response-feedback/12857a7d-89a6-4e0d-a3e7-6c762e5167e2?feedback_type=other)</sup>
yindo commented 2026-02-21 18:21:10 -05:00
Author
Owner
Copy Link
Copy Source

@EvelynBai commented on GitHub (Jan 6, 2025):

Hey there, @EvelynBai! 👋 I'm here to help you with bug fixes, questions, and even becoming a contributor.

The issue of receiving empty data from the Dify API endpoints for conversations and messages might be related to the database permission error you encountered. Here are some steps to troubleshoot and resolve the issue:

  1. Database Permissions: Ensure that the PostgreSQL data directory has the correct permissions. The directory should be owned by the postgres user and group. You can set the ownership with the following command:

    sudo chown -R 999:999 ./volumes/db/data

    The user ID 999 is typically used for the postgres user in Docker containers.

  2. Docker Volumes Configuration: Verify that the Docker volumes are correctly configured in your docker-compose.yaml file. The volume for PostgreSQL should be mapped correctly to ensure data persistence:

    volumes:
  - ./volumes/db/data:/var/lib/postgresql/data

  3. Database Initialization: If the database was not initialized correctly due to permission issues, you might need to remove the existing data directory and allow Docker to reinitialize it:

    sudo rm -rf ./volumes/db/data
sudo docker compose up -d

  4. Check Logs: Review the logs for the PostgreSQL container to ensure that it is starting correctly without errors. You can view the logs using:

    sudo docker logs <db-container-name>

  5. API Key and Authorization: Double-check that the API key is valid and correctly formatted in the Authorization header as Bearer {my-api-key}.

  6. Data Availability: Ensure that there is data available in the database for the API to return. If the database is empty, the API will naturally return an empty data array.

By following these steps, you should be able to resolve the issue with empty data responses from the API. If the problem persists, further investigation into the database setup and API configuration may be necessary.

To continue talking to Dosu, mention @dosu.

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

hi there, I've tried the sudo chown -R 999:999 ./volumes/db/data but it didn't work...

@EvelynBai commented on GitHub (Jan 6, 2025): > Hey there, @EvelynBai! 👋 I'm here to help you with bug fixes, questions, and even becoming a contributor. > > The issue of receiving empty data from the Dify API endpoints for conversations and messages might be related to the database permission error you encountered. Here are some steps to troubleshoot and resolve the issue: > > 1. **Database Permissions**: Ensure that the PostgreSQL data directory has the correct permissions. The directory should be owned by the `postgres` user and group. You can set the ownership with the following command: > ```shell > sudo chown -R 999:999 ./volumes/db/data > ``` > > > > > > > > > > > > The user ID `999` is typically used for the `postgres` user in Docker containers. > 2. **Docker Volumes Configuration**: Verify that the Docker volumes are correctly configured in your `docker-compose.yaml` file. The volume for PostgreSQL should be mapped correctly to ensure data persistence: > ```yaml > volumes: > - ./volumes/db/data:/var/lib/postgresql/data > ``` > 3. **Database Initialization**: If the database was not initialized correctly due to permission issues, you might need to remove the existing data directory and allow Docker to reinitialize it: > ```shell > sudo rm -rf ./volumes/db/data > sudo docker compose up -d > ``` > 4. **Check Logs**: Review the logs for the PostgreSQL container to ensure that it is starting correctly without errors. You can view the logs using: > ```shell > sudo docker logs <db-container-name> > ``` > 5. **API Key and Authorization**: Double-check that the API key is valid and correctly formatted in the Authorization header as `Bearer {my-api-key}`. > 6. **Data Availability**: Ensure that there is data available in the database for the API to return. If the database is empty, the API will naturally return an empty data array. > > By following these steps, you should be able to resolve the issue with empty data responses from the API. If the problem persists, further investigation into the database setup and API configuration may be necessary. > > _To continue talking to [Dosu](https://dosu.dev), mention @dosu._ > > Help Dosu learn! Give it feedback: [Great Response](https://app.dosu.dev/response-feedback/12857a7d-89a6-4e0d-a3e7-6c762e5167e2?feedback_type=great_response) | [Irrelevant Answer](https://app.dosu.dev/response-feedback/12857a7d-89a6-4e0d-a3e7-6c762e5167e2?feedback_type=irrelevant_answer) | [Incorrect Sources](https://app.dosu.dev/response-feedback/12857a7d-89a6-4e0d-a3e7-6c762e5167e2?feedback_type=incorrect_sources) | [Too Verbose](https://app.dosu.dev/response-feedback/12857a7d-89a6-4e0d-a3e7-6c762e5167e2?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/12857a7d-89a6-4e0d-a3e7-6c762e5167e2?feedback_type=hallucination) | [Other](https://app.dosu.dev/response-feedback/12857a7d-89a6-4e0d-a3e7-6c762e5167e2?feedback_type=other) hi there, I've tried the `sudo chown -R 999:999 ./volumes/db/data` but it didn't work...
yindo commented 2026-02-21 18:21:10 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Jan 6, 2025):

If changing the ownership with sudo chown -R 999:999 ./volumes/db/data didn't resolve the issue, here are a few additional steps you can try:

  1. Verify Docker User ID: Ensure that the user ID 999 is indeed the correct ID for the postgres user in your Docker setup. You can check this by running a temporary PostgreSQL container and inspecting the user ID:

    docker run --rm postgres:latest id postgres

  2. Check SELinux/AppArmor: If you're using a system with SELinux or AppArmor, these might be restricting access. You can try disabling them temporarily to see if it resolves the issue.

  3. Recreate the Volume: Sometimes, recreating the volume can help. First, stop the containers, remove the volume, and then start the containers again:

    sudo docker compose down
sudo rm -rf ./volumes/db/data
sudo docker compose up -d

  4. Inspect Docker Logs: Check the logs for any additional error messages that might provide more insight:

    sudo docker logs <db-container-name>

  5. Database Initialization: Ensure that the database is properly initialized. You might need to manually initialize it if the automatic process fails.

  6. Network and Firewall: Ensure that there are no network or firewall rules blocking the connection between your application and the database.

If these steps don't resolve the issue, it might be helpful to look into the specific error messages in the logs for more clues.

To continue talking to Dosu, mention @dosu.

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

@dosubot[bot] commented on GitHub (Jan 6, 2025): <!-- Answer --> If changing the ownership with `sudo chown -R 999:999 ./volumes/db/data` didn't resolve the issue, here are a few additional steps you can try: 1. **Verify Docker User ID**: Ensure that the user ID `999` is indeed the correct ID for the `postgres` user in your Docker setup. You can check this by running a temporary PostgreSQL container and inspecting the user ID: ```bash docker run --rm postgres:latest id postgres ``` 2. **Check SELinux/AppArmor**: If you're using a system with SELinux or AppArmor, these might be restricting access. You can try disabling them temporarily to see if it resolves the issue. 3. **Recreate the Volume**: Sometimes, recreating the volume can help. First, stop the containers, remove the volume, and then start the containers again: ```bash sudo docker compose down sudo rm -rf ./volumes/db/data sudo docker compose up -d ``` 4. **Inspect Docker Logs**: Check the logs for any additional error messages that might provide more insight: ```bash sudo docker logs <db-container-name> ``` 5. **Database Initialization**: Ensure that the database is properly initialized. You might need to manually initialize it if the automatic process fails. 6. **Network and Firewall**: Ensure that there are no network or firewall rules blocking the connection between your application and the database. If these steps don't resolve the issue, it might be helpful to look into the specific error messages in the logs for more clues. <!-- 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/263f65bf-884a-4ca3-b41f-91877cc50ec8?feedback_type=great_response) | [Irrelevant Answer](https://app.dosu.dev/response-feedback/263f65bf-884a-4ca3-b41f-91877cc50ec8?feedback_type=irrelevant_answer) | [Incorrect Sources](https://app.dosu.dev/response-feedback/263f65bf-884a-4ca3-b41f-91877cc50ec8?feedback_type=incorrect_sources) | [Too Verbose](https://app.dosu.dev/response-feedback/263f65bf-884a-4ca3-b41f-91877cc50ec8?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/263f65bf-884a-4ca3-b41f-91877cc50ec8?feedback_type=hallucination) | [Other](https://app.dosu.dev/response-feedback/263f65bf-884a-4ca3-b41f-91877cc50ec8?feedback_type=other)</sup>
yindo commented 2026-02-21 18:21:10 -05:00
Author
Owner
Copy Link
Copy Source

@EvelynBai commented on GitHub (Jan 7, 2025):

Hey @crazywoola! I’m still having trouble with this issue. Would you mind taking a look? Any help would be greatly appreciated.

@EvelynBai commented on GitHub (Jan 7, 2025): Hey @crazywoola! I’m still having trouble with this issue. Would you mind taking a look? Any help would be greatly appreciated.
yindo commented 2026-02-21 18:21:10 -05:00
Author
Owner
Copy Link
Copy Source

@Akaike commented on GitHub (Jan 7, 2025):

Have the exact same issue when running docker compose up on macOS.
db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied

@Akaike commented on GitHub (Jan 7, 2025): Have the exact same issue when running docker compose up on macOS. `db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied`
yindo commented 2026-02-21 18:21:10 -05:00
Author
Owner
Copy Link
Copy Source

@EvelynBai commented on GitHub (Jan 7, 2025):

Have the exact same issue when running docker compose up on macOS. db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied

Hi! I solved 'permission denied' problem by chmod -R 777 ./volumes/db/data, but I'm not sure if this is a good solution. However, API calls still return an empty data field {"limit": 20, "has_more": false, "data": []}

@EvelynBai commented on GitHub (Jan 7, 2025): > Have the exact same issue when running docker compose up on macOS. `db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied db-1 | chown: /var/lib/postgresql/data/pgdata: Permission denied` Hi! I solved 'permission denied' problem by chmod -R 777 ./volumes/db/data, but I'm not sure if this is a good solution. However, API calls still return an empty data field `{"limit": 20, "has_more": false, "data": []}`
yindo commented 2026-02-21 18:21:10 -05:00
Author
Owner
Copy Link
Copy Source

@EvelynBai commented on GitHub (Jan 8, 2025):

Hey @crazywoola! I’m trying to figure out where the user value in the API comes from. I am using the user field in the log (screenshot attached below), but the return data field is empty.
截屏2025-01-08 下午3 14 23
Interestingly, running:
curl -X GET 'http://10.6.43.33/v1/workflows/logs' --header 'Authorization: Bearer {my-api-key}'
works fine, so I suspect the user field might not be what I initially thought.

@EvelynBai commented on GitHub (Jan 8, 2025): Hey @crazywoola! I’m trying to figure out where the user value in the API comes from. I am using the user field in the log (screenshot attached below), but the return data field is empty. <img width="1386" alt="截屏2025-01-08 下午3 14 23" src="https://github.com/user-attachments/assets/637b1200-2de1-4c24-b51f-3213804dea46" /> Interestingly, running: `curl -X GET 'http://10.6.43.33/v1/workflows/logs' --header 'Authorization: Bearer {my-api-key}'` works fine, so I suspect the user field might not be what I initially thought.
yindo commented 2026-02-21 18:21:10 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Feb 8, 2025):

Hi, @EvelynBai. 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 issue with the Dify API returning empty data for Conversations and Messages in a self-hosted Docker setup.
  • Troubleshooting steps, including adjusting directory permissions and Docker volume configurations, were attempted without success.
  • I suggested verifying Docker user IDs and checking SELinux/AppArmor settings, but these did not resolve the issue.
  • You and another user, Akaike, experienced permission issues; a temporary fix using chmod -R 777 was applied, but the API still returns empty data.
  • You suspect the issue might be related to the user field in the API.

Next Steps:

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

Thank you for your understanding and contribution!

@dosubot[bot] commented on GitHub (Feb 8, 2025): Hi, @EvelynBai. 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 issue with the Dify API returning empty data for Conversations and Messages in a self-hosted Docker setup. - Troubleshooting steps, including adjusting directory permissions and Docker volume configurations, were attempted without success. - I suggested verifying Docker user IDs and checking SELinux/AppArmor settings, but these did not resolve the issue. - You and another user, Akaike, experienced permission issues; a temporary fix using `chmod -R 777` was applied, but the API still returns empty data. - You suspect the issue might be related to the user field in the API. **Next Steps:** - Please confirm if this issue is still relevant to the latest version of the Dify repository. If so, you can keep the discussion open by commenting on the issue. - Otherwise, this issue will be automatically closed in 15 days. Thank you for your understanding and contribution!
yindo commented 2026-02-21 18:21:10 -05:00
Author
Owner
Copy Link
Copy Source

@crazywoola commented on GitHub (Feb 12, 2025):

@EvelynBai

Interestingly, running:
curl -X GET 'http://10.6.43.33/v1/workflows/logs' --header 'Authorization: Bearer {my-api-key}'
works fine, so I suspect the user field might not be what I initially thought.

The user name displayed in the console maybe the end_user_id or admin_user_id it depends on how you call the application. For now, we do not provide a way to fetch logs by using application, logs can be fetched only when you are call the /chat-messages by API.

@crazywoola commented on GitHub (Feb 12, 2025): @EvelynBai > Interestingly, running: curl -X GET 'http://10.6.43.33/v1/workflows/logs' --header 'Authorization: Bearer {my-api-key}' works fine, so I suspect the user field might not be what I initially thought. The user name displayed in the console maybe the `end_user_id` or `admin_user_id` it depends on how you call the application. For now, we do not provide a way to fetch logs by using application, logs can be fetched only when you are call the /chat-messages by API.
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 good first issue 🐞 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#7549
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?