langgenius/dify
1
0
Fork 0
mirror of https://github.com/langgenius/dify.git synced 2026-07-19 08:35:20 -04:00
Code Issues 775 Packages Projects Releases 10 Wiki Activity

/conversations API fails to retrieve full history for specific users (older history cut off based on thread creation date) #20699

New Issue
Closed
opened 2026-02-21 20:08:31 -05:00 by yindo · 7 comments
yindo commented 2026-02-21 20:08:31 -05:00
Owner
Copy Link
Copy Source

Originally created by @odekocha on GitHub (Nov 30, 2025).

Originally assigned to: @laipz8200 on GitHub.

Self Checks

  • I have read the Contributing Guide and Language Policy.
  • 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, otherwise it will be closed.
  • 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：）
  • Please do not modify this template :) and fill in all the required fields.

Dify version

1.10.1

Cloud or Self Hosted

Cloud

Steps to reproduce

Description
There is an issue where the /conversations API does not correctly return the full conversation list for certain users.
For example, although User 1 has around 50 threads stored in Dify, the API only returns 2 threads.

Observed Behavior
It appears that the API applies an unintended cutoff based on the date when a new conversation thread is created via the API.

  • If a certain user creates a new thread on Nov 21, the API only returns threads created on or after Nov 21.
  • Conversation history from before Nov 20 becomes inaccessible through the API, even though it still exists in the system.

Reproducibility
This issue was consistently reproduced:

  • A new conversation was created via API on Nov 21, 22, 23, 24, and 25.
  • In each case, the API only returned conversations created after that date.
  • A separate test user account was used for each date.
  • (No data exists for Nov 26–27, so these dates could not be tested.)

Exception Case (Working Pattern)
If a conversation was created on Nov 20, and the next conversation was created on Nov 28 (skipping the problematic dates),
the API successfully returned all history, including both older and newer threads.

✔️ Expected Behavior

The /conversations API should return all conversation threads associated with the user, regardless of when the latest thread was created.

❌ Actual Behavior

When calling GET /conversations, only the conversations created after the cutoff date are returned.
Older conversations (approximately 48 threads) are missing from the API response, even though they exist in the database.

Originally created by @odekocha on GitHub (Nov 30, 2025). Originally assigned to: @laipz8200 on GitHub. ### Self Checks - [x] I have read the [Contributing Guide](https://github.com/langgenius/dify/blob/main/CONTRIBUTING.md) and [Language Policy](https://github.com/langgenius/dify/issues/1542). - [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, otherwise it will be closed. - [x] 【中文用户 & Non English User】请使用英语提交，否则会被关闭 ：） - [x] Please do not modify this template :) and fill in all the required fields. ### Dify version 1.10.1 ### Cloud or Self Hosted Cloud ### Steps to reproduce **Description** There is an issue where the `/conversations` API does not correctly return the full conversation list for certain users. For example, although User 1 has around 50 threads stored in Dify, the API only returns 2 threads. **Observed Behavior** It appears that the API applies an unintended cutoff based on the date when a new conversation thread is created via the API. - If a certain user creates a new thread on Nov 21, the API only returns threads created on or after Nov 21. - Conversation history from before Nov 20 becomes inaccessible through the API, even though it still exists in the system. **Reproducibility** This issue was consistently reproduced: - A new conversation was created via API on Nov 21, 22, 23, 24, and 25. - In each case, the API only returned conversations created after that date. - A separate test user account was used for each date. - (No data exists for Nov 26–27, so these dates could not be tested.) **Exception Case (Working Pattern)** If a conversation was created on Nov 20, and the next conversation was created on Nov 28 (skipping the problematic dates), the API successfully returned all history, including both older and newer threads. ### ✔️ Expected Behavior The `/conversations` API should return all conversation threads associated with the user, regardless of when the latest thread was created. ### ❌ Actual Behavior When calling `GET /conversations`, only the conversations created after the cutoff date are returned. Older conversations (approximately 48 threads) are missing from the API response, even though they exist in the database.
yindo added the 🐞 bugcloud labels 2026-02-21 20:08:31 -05:00
yindo closed this issue 2026-02-21 20:08:31 -05:00
yindo commented 2026-02-21 20:08:31 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Nov 30, 2025):

Hi @odekocha! I'm Dosu and I’m helping the dify team.

The cutoff in the /conversations API is caused by strict filtering on user context and conversation source. Dify enforces that API endpoints only return conversations created by the API for the same user/session context, and not those created via the Web UI or in a different context. This is by design and is enforced in the backend code, which checks both the user and the source of each conversation. If these don't match, older conversations become inaccessible via the API—even if they exist in the database and are visible in the frontend UI. There is no explicit date-based cutoff in the code, but pagination and filtering logic (especially if using last_id or mixing creation methods) can make it appear that older threads are missing if they were created in a different context or before an upgrade [source].

A recent fix addressed legacy end user lookup for conversations created before upgrading to 1.10.0, but strict separation between API and UI-created conversations remains for new threads [source].

To ensure all conversations are accessible via the API, always create and retrieve them using the same method and user/session context. Avoid mixing API and UI-created threads for the same user. If you need to access older conversations created in a different context, there is currently no built-in migration or configuration to bridge this gap. Workarounds include duplicating workflows or consistently using the API for both creation and retrieval [source].

If you suspect user ID mapping issues (e.g., sys.user_id being set to a session ID instead of the actual user ID), double-check your workflow configuration, as this can also cause missing conversations in API responses [source].

Let me know if you need more technical details or have a specific scenario to troubleshoot.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Nov 30, 2025): <!-- Greeting --> Hi @odekocha! I'm [Dosu](https://go.dosu.dev/dosubot) and I’m helping the dify team. <!-- Answer --> The cutoff in the `/conversations` API is caused by strict filtering on user context and conversation source. Dify enforces that API endpoints only return conversations created by the API for the same user/session context, and not those created via the Web UI or in a different context. This is by design and is enforced in the backend code, which checks both the user and the source of each conversation. If these don't match, older conversations become inaccessible via the API—even if they exist in the database and are visible in the frontend UI. There is no explicit date-based cutoff in the code, but pagination and filtering logic (especially if using `last_id` or mixing creation methods) can make it appear that older threads are missing if they were created in a different context or before an upgrade [[source]](https://github.com/langgenius/dify/issues/28375). A recent fix addressed legacy end user lookup for conversations created before upgrading to 1.10.0, but strict separation between API and UI-created conversations remains for new threads [[source]](https://github.com/langgenius/dify/pull/28462). To ensure all conversations are accessible via the API, always create and retrieve them using the same method and user/session context. Avoid mixing API and UI-created threads for the same user. If you need to access older conversations created in a different context, there is currently no built-in migration or configuration to bridge this gap. Workarounds include duplicating workflows or consistently using the API for both creation and retrieval [[source]](https://github.com/langgenius/dify/issues/25768). If you suspect user ID mapping issues (e.g., `sys.user_id` being set to a session ID instead of the actual user ID), double-check your workflow configuration, as this can also cause missing conversations in API responses [[source]](https://github.com/langgenius/dify/issues/15916). Let me know if you need more technical details or have a specific scenario to troubleshoot. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/3e5fd4aa-f608-4390-ae9c-f1c0abbaf270?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/3e5fd4aa-f608-4390-ae9c-f1c0abbaf270?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/3e5fd4aa-f608-4390-ae9c-f1c0abbaf270?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/3e5fd4aa-f608-4390-ae9c-f1c0abbaf270?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/3e5fd4aa-f608-4390-ae9c-f1c0abbaf270?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/3e5fd4aa-f608-4390-ae9c-f1c0abbaf270?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/3e5fd4aa-f608-4390-ae9c-f1c0abbaf270?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=The%20cutoff%20in%20the%20%60/conversations%60%20API%20is%20caused%20by%20strict%20filtering%20on%20user%20context%20and%20conversation%20source.%20Dify%20enforces%20that%20API%20endpoints%20only%20return%20conversations%20created%20by%20the%20API%20for%20the%20same%20user/session%20context%2C%20and%20not%20those%20created%20via%20the%20Web%20UI%20or%20in%20a%20different%20context.%20This%20is%20by%20design%20and%20is%20enforced%20in%20the%20backend%20code%2C%20which%20checks%20both%20the%20user%20and%20the%20source%20of%20each%20conversation.%20If%20these%20don%27t%20match%2C%20older%20conversations%20become%20inaccessible%20via%20the%20API%E2%80%94even%20if%20they%20exist%20in%20the%20database%20and%20are%20visible%20in%20the%20frontend%20UI.%20There%20is%20no%20explicit%20date-based%20cutoff%20in%20the%20code%2C%20but%20pagination%20and%20filtering%20logic%20%28especially%20if%20using%20%60last_id%60%20or%20mixing%20creation%20methods%29%20can%20make%20it%20appear%20that%20older%20threads%20are%20missing%20if%20they%20were%20created%20in%20a%20different%20context%20or%20before%20an%20upgrade%20%5B%5Bsource%5D%5D%28https%3A//github.com/langgenius/dify/issues/28375%29.%0A%0AA%20recent%20fix%20addressed%20legacy%20end%20user%20lookup%20for%20conversations%20created%20before%20upgrading%20to%201.10.0%2C%20but%20strict%20separation%20between%20API%20and%20UI-created%20conversations%20remains%20for%20new%20threads%20%5B%5Bsource%5D%5D%28https%3A//github.com/langgenius/dify/pull/28462%29.%0A%0ATo%20ensure%20all%20conversations%20are%20accessible%20via%20the%20API%2C%20always%20create%20and%20retrieve%20them%20using%20the%20same%20method%20and%20user/session%20context.%20Avoid%20mixing%20API%20and%20UI-created%20threads%20for%20the%20same%20user.%20If%20you%20need%20to%20access%20older%20conversations%20created%20in%20a%20different%20context%2C%20there%20is%20currently%20no%20built-in%20migration%20or%20configuration%20to%20bridge%20this%20gap.%20Workarounds%20include%20duplicating%20workflows%20or%20consistently%20using%20the%20API%20for%20both%20creation%20and%20retrieval%20%5B%5Bsource%5D%5D%28https%3A//github.com/langgenius/dify/issues/25768%29.%0A%0AIf%20you%20suspect%20user%20ID%20mapping%20issues%20%28e.g.%2C%20%60sys.user_id%60%20being%20set%20to%20a%20session%20ID%20instead%20of%20the%20actual%20user%20ID%29%2C%20double-check%20your%20workflow%20configuration%2C%20as%20this%20can%20also%20cause%20missing%20conversations%20in%20API%20responses%20%5B%5Bsource%5D%5D%28https%3A//github.com/langgenius/dify/issues/15916%29.%0A%0ALet%20me%20know%20if%20you%20need%20more%20technical%20details%20or%20have%20a%20specific%20scenario%20to%20troubleshoot.)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/28957)
yindo commented 2026-02-21 20:08:32 -05:00
Author
Owner
Copy Link
Copy Source

@odekocha commented on GitHub (Nov 30, 2025):

@dosu
Thanks for the explanation, Dosu. However, just to clarify, I verified this issue entirely through API requests. I did not use the Web UI to create any of the threads mentioned in the report.

As stated in the issue description:

Note: All verification steps and interactions described below were performed exclusively via API requests, not through the Dify Web UI.

Even when using only the API (with the same user context), the API correctly retrieves all history when threads are created on certain dates (e.g., Nov 20, Nov 28), but it fails to retrieve the older history when a thread is created on specific dates (Nov 21–25).

Since there is no mixing of API and UI contexts in my tests, this “date-dependent cutoff” behavior appears to be different from the “source filtering” behavior you described.
Could you please take another look at this?

@odekocha commented on GitHub (Nov 30, 2025): @dosu Thanks for the explanation, Dosu. However, just to clarify, I verified this issue entirely through API requests. I did not use the Web UI to create any of the threads mentioned in the report. As stated in the issue description: > Note: All verification steps and interactions described below were performed exclusively via API requests, not through the Dify Web UI. Even when using only the API (with the same user context), the API correctly retrieves all history when threads are created on certain dates (e.g., Nov 20, Nov 28), but it fails to retrieve the older history when a thread is created on specific dates (Nov 21–25). Since there is no mixing of API and UI contexts in my tests, this “date-dependent cutoff” behavior appears to be different from the “source filtering” behavior you described. Could you please take another look at this?
yindo commented 2026-02-21 20:08:32 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Nov 30, 2025):

Thanks for clarifying your test setup. Based on the code and recent changes, there’s no explicit date-based cutoff in the /conversations API, but the pagination logic can cause older conversations to be excluded if the last_id parameter is set to a recent conversation. The API paginates results by sorting (default is -updated_at), and if last_id points to a newer thread, only conversations with a more recent timestamp are returned—older ones are filtered out, even if they exist in the database. This can look like a date-dependent cutoff if the pagination state or parameters change after creating new threads [source].

If you’re not using last_id, or always starting from the first page, you should see all conversations for the user context. If you are using last_id, double-check its value and the sort order. Also, a recent migration updated how message threading works for API-created conversations after 2024-09-29, which could affect visibility or linking for threads created after that date [source].

For troubleshooting: compare the API request parameters (especially last_id and sort_by) between successful and unsuccessful retrievals, and check the database for differences in invoke_from, from_source, timestamps, and user IDs for the missing conversations. This should help isolate why certain threads are excluded. If you need more technical details or want to share example requests/responses, I can help dig deeper.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Nov 30, 2025): <!-- Answer --> Thanks for clarifying your test setup. Based on the code and recent changes, there’s no explicit date-based cutoff in the `/conversations` API, but the pagination logic can cause older conversations to be excluded if the `last_id` parameter is set to a recent conversation. The API paginates results by sorting (default is `-updated_at`), and if `last_id` points to a newer thread, only conversations with a more recent timestamp are returned—older ones are filtered out, even if they exist in the database. This can look like a date-dependent cutoff if the pagination state or parameters change after creating new threads [[source](https://github.com/langgenius/dify/blob/247069c7e96fa1763fc9dd9da001bc5683c73a64/api/services/conversation_service.py#L49-L97)]. If you’re not using `last_id`, or always starting from the first page, you should see all conversations for the user context. If you are using `last_id`, double-check its value and the sort order. Also, a recent migration updated how message threading works for API-created conversations after 2024-09-29, which could affect visibility or linking for threads created after that date [[source](https://github.com/langgenius/dify/blob/247069c7e96fa1763fc9dd9da001bc5683c73a64/api/migrations/versions/2024_10_09_1329-d8e744d88ed6_fix_wrong_service_api_history.py#L20-L47)]. For troubleshooting: compare the API request parameters (especially `last_id` and `sort_by`) between successful and unsuccessful retrievals, and check the database for differences in `invoke_from`, `from_source`, timestamps, and user IDs for the missing conversations. This should help isolate why certain threads are excluded. If you need more technical details or want to share example requests/responses, I can help dig deeper. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/2318f649-ca3d-4619-965c-83eea89eaa62?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/2318f649-ca3d-4619-965c-83eea89eaa62?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/2318f649-ca3d-4619-965c-83eea89eaa62?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/2318f649-ca3d-4619-965c-83eea89eaa62?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/2318f649-ca3d-4619-965c-83eea89eaa62?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/2318f649-ca3d-4619-965c-83eea89eaa62?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/2318f649-ca3d-4619-965c-83eea89eaa62?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=Thanks%20for%20clarifying%20your%20test%20setup.%20Based%20on%20the%20code%20and%20recent%20changes%2C%20there%E2%80%99s%20no%20explicit%20date-based%20cutoff%20in%20the%20%60/conversations%60%20API%2C%20but%20the%20pagination%20logic%20can%20cause%20older%20conversations%20to%20be%20excluded%20if%20the%20%60last_id%60%20parameter%20is%20set%20to%20a%20recent%20conversation.%20The%20API%20paginates%20results%20by%20sorting%20%28default%20is%20%60-updated_at%60%29%2C%20and%20if%20%60last_id%60%20points%20to%20a%20newer%20thread%2C%20only%20conversations%20with%20a%20more%20recent%20timestamp%20are%20returned%E2%80%94older%20ones%20are%20filtered%20out%2C%20even%20if%20they%20exist%20in%20the%20database.%20This%20can%20look%20like%20a%20date-dependent%20cutoff%20if%20the%20pagination%20state%20or%20parameters%20change%20after%20creating%20new%20threads%20%5B%5Bsource%5D%28https%3A//github.com/langgenius/dify/blob/247069c7e96fa1763fc9dd9da001bc5683c73a64/api/services/conversation_service.py%23L49-L97%29%5D.%0A%0AIf%20you%E2%80%99re%20not%20using%20%60last_id%60%2C%20or%20always%20starting%20from%20the%20first%20page%2C%20you%20should%20see%20all%20conversations%20for%20the%20user%20context.%20If%20you%20are%20using%20%60last_id%60%2C%20double-check%20its%20value%20and%20the%20sort%20order.%20Also%2C%20a%20recent%20migration%20updated%20how%20message%20threading%20works%20for%20API-created%20conversations%20after%202024-09-29%2C%20which%20could%20affect%20visibility%20or%20linking%20for%20threads%20created%20after%20that%20date%20%5B%5Bsource%5D%28https%3A//github.com/langgenius/dify/blob/247069c7e96fa1763fc9dd9da001bc5683c73a64/api/migrations/versions/2024_10_09_1329-d8e744d88ed6_fix_wrong_service_api_history.py%23L20-L47%29%5D.%0A%0AFor%20troubleshooting%3A%20compare%20the%20API%20request%20parameters%20%28especially%20%60last_id%60%20and%20%60sort_by%60%29%20between%20successful%20and%20unsuccessful%20retrievals%2C%20and%20check%20the%20database%20for%20differences%20in%20%60invoke_from%60%2C%20%60from_source%60%2C%20timestamps%2C%20and%20user%20IDs%20for%20the%20missing%20conversations.%20This%20should%20help%20isolate%20why%20certain%20threads%20are%20excluded.%20If%20you%20need%20more%20technical%20details%20or%20want%20to%20share%20example%20requests/responses%2C%20I%20can%20help%20dig%20deeper.)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/28957)
yindo commented 2026-02-21 20:08:32 -05:00
Author
Owner
Copy Link
Copy Source

@odekocha commented on GitHub (Nov 30, 2025):

@dosu
Thanks for the suggestion.

I reviewed my request again, and I’d like to clarify a few points:

I am not providing the last_id parameter (this is a first-page request).

The API response explicitly returns has_more: false.

Because the API reports has_more = false, there is no way to retrieve any additional pages.
As a result, the API behaves as though the older conversations do not exist, even though they are present in the database.

Given that last_id is not being used and the API signals the end of the list at the first page, I believe this is not a pagination-usage issue but a problem in the filtering logic.
I hope this clarification helps, and I would appreciate it if you could take another look.

@odekocha commented on GitHub (Nov 30, 2025): @dosu Thanks for the suggestion. I reviewed my request again, and I’d like to clarify a few points: I am not providing the `last_id` parameter (this is a first-page request). The API response explicitly returns `has_more`: false. Because the API reports `has_more` = false, there is no way to retrieve any additional pages. As a result, the API behaves as though the older conversations do not exist, even though they are present in the database. Given that last_id is not being used and the API signals the end of the list at the first page, I believe this is not a pagination-usage issue but a problem in the filtering logic. I hope this clarification helps, and I would appreciate it if you could take another look.
yindo commented 2026-02-21 20:08:32 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Nov 30, 2025):

There’s no explicit date-based cutoff in the code, but the API’s filtering logic is strict: it only returns conversations that match the current user context, source (from_source), and invoke_from value, regardless of pagination or the last_id parameter. If any of these fields differ between your older and newer conversations—even if all were created via the API—those older threads will be excluded from the results, and has_more will be false on the first page. This can happen due to subtle differences in user IDs, from_source, or invoke_from values (for example, if the API context or token changed between sessions) source.

I recommend checking the metadata for both missing and returned conversations in your database—specifically from_end_user_id, from_source, invoke_from, and app_id—to see if there are any differences. If everything matches and the issue persists, sharing anonymized examples of the relevant conversation records (with those fields) could help pinpoint the cause.

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Nov 30, 2025): <!-- Answer --> There’s no explicit date-based cutoff in the code, but the API’s filtering logic is strict: it only returns conversations that match the current user context, source (`from_source`), and `invoke_from` value, regardless of pagination or the `last_id` parameter. If any of these fields differ between your older and newer conversations—even if all were created via the API—those older threads will be excluded from the results, and `has_more` will be `false` on the first page. This can happen due to subtle differences in user IDs, `from_source`, or `invoke_from` values (for example, if the API context or token changed between sessions) [source](https://github.com/langgenius/dify/blob/247069c7e96fa1763fc9dd9da001bc5683c73a64/api/services/conversation_service.py#L49-L97). I recommend checking the metadata for both missing and returned conversations in your database—specifically `from_end_user_id`, `from_source`, `invoke_from`, and `app_id`—to see if there are any differences. If everything matches and the issue persists, sharing anonymized examples of the relevant conversation records (with those fields) could help pinpoint the cause. <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/f0cfc279-0736-4030-b116-e36d638b58c6?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/f0cfc279-0736-4030-b116-e36d638b58c6?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/f0cfc279-0736-4030-b116-e36d638b58c6?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/f0cfc279-0736-4030-b116-e36d638b58c6?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/f0cfc279-0736-4030-b116-e36d638b58c6?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/f0cfc279-0736-4030-b116-e36d638b58c6?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/f0cfc279-0736-4030-b116-e36d638b58c6?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=There%E2%80%99s%20no%20explicit%20date-based%20cutoff%20in%20the%20code%2C%20but%20the%20API%E2%80%99s%20filtering%20logic%20is%20strict%3A%20it%20only%20returns%20conversations%20that%20match%20the%20current%20user%20context%2C%20source%20%28%60from_source%60%29%2C%20and%20%60invoke_from%60%20value%2C%20regardless%20of%20pagination%20or%20the%20%60last_id%60%20parameter.%20If%20any%20of%20these%20fields%20differ%20between%20your%20older%20and%20newer%20conversations%E2%80%94even%20if%20all%20were%20created%20via%20the%20API%E2%80%94those%20older%20threads%20will%20be%20excluded%20from%20the%20results%2C%20and%20%60has_more%60%20will%20be%20%60false%60%20on%20the%20first%20page.%20This%20can%20happen%20due%20to%20subtle%20differences%20in%20user%20IDs%2C%20%60from_source%60%2C%20or%20%60invoke_from%60%20values%20%28for%20example%2C%20if%20the%20API%20context%20or%20token%20changed%20between%20sessions%29%20%5Bsource%5D%28https%3A//github.com/langgenius/dify/blob/247069c7e96fa1763fc9dd9da001bc5683c73a64/api/services/conversation_service.py%23L49-L97%29.%0A%0AI%20recommend%20checking%20the%20metadata%20for%20both%20missing%20and%20returned%20conversations%20in%20your%20database%E2%80%94specifically%20%60from_end_user_id%60%2C%20%60from_source%60%2C%20%60invoke_from%60%2C%20and%20%60app_id%60%E2%80%94to%20see%20if%20there%20are%20any%20differences.%20If%20everything%20matches%20and%20the%20issue%20persists%2C%20sharing%20anonymized%20examples%20of%20the%20relevant%20conversation%20records%20%28with%20those%20fields%29%20could%20help%20pinpoint%20the%20cause.)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/28957)
yindo commented 2026-02-21 20:08:32 -05:00
Author
Owner
Copy Link
Copy Source

@odekocha commented on GitHub (Nov 30, 2025):

@dosu
Thanks for the advice regarding the database check.

Since I am using the Dify Cloud version, I do not have direct access to the database to verify columns such as invoke_from or from_source.

Given this limitation, could you advise on what kinds of checks or verifications I can perform on the client side that might help identify the cause?
For example, would examining API response headers, Web UI logs, or any other available information be useful?

@odekocha commented on GitHub (Nov 30, 2025): @dosu Thanks for the advice regarding the database check. Since I am using the Dify Cloud version, I do not have direct access to the database to verify columns such as invoke_from or from_source. Given this limitation, could you advise on what kinds of checks or verifications I can perform on the client side that might help identify the cause? For example, would examining API response headers, Web UI logs, or any other available information be useful?
yindo commented 2026-02-21 20:08:32 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Nov 30, 2025):

You can inspect the metadata fields included in each conversation object returned by the /conversations API—specifically, from_source, from_end_user_id, and invoke_from (if present). Compare these fields across the conversations that are visible and those that are missing to look for differences; mismatches here often explain why some threads are excluded by the API’s filtering logic. The API response body exposes these fields, but response headers do not include extra filtering or context metadata, so focus on the response body itself for troubleshooting.

If you’re using different API tokens, authentication methods, or request headers between sessions, check for differences there as well, since these can affect which conversations are returned. The Dify Cloud Web UI typically doesn’t provide logs for API-only workflows, but if you have access to any user/session context in the UI, reviewing it may help spot inconsistencies.

If you need to share anonymized examples of the returned conversation objects (with these metadata fields), that could help further pinpoint the cause.
Reference: API response fields and filtering logic

To reply, just mention @dosu.

How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other

Chat with Dosu Open in Cursor Join Discord Share on X

@dosubot[bot] commented on GitHub (Nov 30, 2025): <!-- Answer --> You can inspect the metadata fields included in each conversation object returned by the /conversations API—specifically, from_source, from_end_user_id, and invoke_from (if present). Compare these fields across the conversations that are visible and those that are missing to look for differences; mismatches here often explain why some threads are excluded by the API’s filtering logic. The API response body exposes these fields, but response headers do not include extra filtering or context metadata, so focus on the response body itself for troubleshooting. If you’re using different API tokens, authentication methods, or request headers between sessions, check for differences there as well, since these can affect which conversations are returned. The Dify Cloud Web UI typically doesn’t provide logs for API-only workflows, but if you have access to any user/session context in the UI, reviewing it may help spot inconsistencies. If you need to share anonymized examples of the returned conversation objects (with these metadata fields), that could help further pinpoint the cause. [Reference: API response fields and filtering logic](https://github.com/langgenius/dify/blob/0af8a7b958dd96425b4b8659558f324c30fed8e2/api/fields/conversation_fields.py#L68-L141) <!-- Dosu Comment Footer --> *To reply, just mention [@dosu](https://go.dosu.dev/dosubot).* --- <sup>How did I do? [Good](https://app.dosu.dev/response-feedback/3262af92-54d6-41fd-b46c-eab2be7dd710?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/3262af92-54d6-41fd-b46c-eab2be7dd710?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/3262af92-54d6-41fd-b46c-eab2be7dd710?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/3262af92-54d6-41fd-b46c-eab2be7dd710?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/3262af92-54d6-41fd-b46c-eab2be7dd710?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/3262af92-54d6-41fd-b46c-eab2be7dd710?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/3262af92-54d6-41fd-b46c-eab2be7dd710?feedback_type=other)</sup> [![Chat with Dosu](https://dosu.dev/dosu-chat-badge.svg)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github)&nbsp;[![Open in Cursor](https://dosu.dev/dosu-in-cursor.svg)](https://cursor.com/link/prompt?text=You%20can%20inspect%20the%20metadata%20fields%20included%20in%20each%20conversation%20object%20returned%20by%20the%20/conversations%20API%E2%80%94specifically%2C%20from_source%2C%20from_end_user_id%2C%20and%20invoke_from%20%28if%20present%29.%20Compare%20these%20fields%20across%20the%20conversations%20that%20are%20visible%20and%20those%20that%20are%20missing%20to%20look%20for%20differences%3B%20mismatches%20here%20often%20explain%20why%20some%20threads%20are%20excluded%20by%20the%20API%E2%80%99s%20filtering%20logic.%20The%20API%20response%20body%20exposes%20these%20fields%2C%20but%20response%20headers%20do%20not%20include%20extra%20filtering%20or%20context%20metadata%2C%20so%20focus%20on%20the%20response%20body%20itself%20for%20troubleshooting.%20%0A%0AIf%20you%E2%80%99re%20using%20different%20API%20tokens%2C%20authentication%20methods%2C%20or%20request%20headers%20between%20sessions%2C%20check%20for%20differences%20there%20as%20well%2C%20since%20these%20can%20affect%20which%20conversations%20are%20returned.%20The%20Dify%20Cloud%20Web%20UI%20typically%20doesn%E2%80%99t%20provide%20logs%20for%20API-only%20workflows%2C%20but%20if%20you%20have%20access%20to%20any%20user/session%20context%20in%20the%20UI%2C%20reviewing%20it%20may%20help%20spot%20inconsistencies.%0A%0AIf%20you%20need%20to%20share%20anonymized%20examples%20of%20the%20returned%20conversation%20objects%20%28with%20these%20metadata%20fields%29%2C%20that%20could%20help%20further%20pinpoint%20the%20cause.%20%20%0A%5BReference%3A%20API%20response%20fields%20and%20filtering%20logic%5D%28https%3A//github.com/langgenius/dify/blob/0af8a7b958dd96425b4b8659558f324c30fed8e2/api/fields/conversation_fields.py%23L68-L141%29)&nbsp;[![Join Discord](https://img.shields.io/badge/join-5865F2?logo=discord&logoColor=white&label=)](https://go.dosu.dev/discord-bot)&nbsp;[![Share on X](https://img.shields.io/badge/X-share-black)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/28957)
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 cloud 🐞 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#20699
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?