React is quite unstable #21899

Closed
opened 2026-02-21 20:14:47 -05:00 by yindo · 3 comments
Owner

Originally created by @xiaotang-12-ops on GitHub (Jan 26, 2026).

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.11.2

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

React is quite unstable — the mode even outputs all JSON fields for tool calls, and what’s more, the memory nodes are present at times and missing at others.
I recall that with Chatflow, all conversation history was visible in the logs before: for instance, what the user’s first message was, what the corresponding response was, what the second user message was, and so on. But I’ve noticed that this conversation history is no longer available in the logs now.

✔️ Expected Behavior

none

Actual Behavior

none

Originally created by @xiaotang-12-ops on GitHub (Jan 26, 2026). ### 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.11.2 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce React is quite unstable — the mode even outputs all JSON fields for tool calls, and what’s more, the memory nodes are present at times and missing at others. I recall that with Chatflow, all conversation history was visible in the logs before: for instance, what the user’s first message was, what the corresponding response was, what the second user message was, and so on. But I’ve noticed that this conversation history is no longer available in the logs now. ### ✔️ Expected Behavior none ### ❌ Actual Behavior none
yindo added the 🐞 bug label 2026-02-21 20:14:47 -05:00
yindo closed this issue 2026-02-21 20:14:47 -05:00
Author
Owner

@dosubot[bot] commented on GitHub (Jan 26, 2026):

There are known issues in Dify v1.11.2 (self-hosted) that match what you're seeing: React mode can output unstable or excessive JSON for tool calls, and memory nodes may appear or disappear inconsistently. This instability is linked to recent changes in how conversation variables are persisted and how logs are structured, as well as a bug where internal node metadata (like [[node]]...[[/node]]) leaks into the conversation context, causing models to mimic these tags and pollute logs. The expected behavior is for only user and assistant messages to be included in the LLM context, but this filtering is currently broken in v1.11.2 [source].

For missing conversation history in logs, this is partly due to frontend state/query invalidation—after switching conversations, the UI may not reload messages unless you refresh or switch again. This is a known bug in the frontend logic (see issues #29820, #31422, #30378), not a deployment or config error [source].

There are no config changes or workarounds that fully resolve these issues in v1.11.2. Upgrading to a newer version (v1.11.4 or later) is recommended, as several related bugs have been fixed there. In the meantime, you can try manually refreshing the page or toggling conversations to restore history display, and if you need to patch the node metadata leak, you would need to sanitize message content in the backend before it reaches the LLM [source].

If you need to keep using v1.11.2, enabling memory features in your agent.yaml and adjusting token limits may help with memory node consistency, but won't fix the frontend or logging bugs. There are no automated scripts deleting logs, so your data should remain in the database unless affected by a bug or manual operation [source].

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 (Jan 26, 2026): <!-- Answer --> There are known issues in Dify v1.11.2 (self-hosted) that match what you're seeing: React mode can output unstable or excessive JSON for tool calls, and memory nodes may appear or disappear inconsistently. This instability is linked to recent changes in how conversation variables are persisted and how logs are structured, as well as a bug where internal node metadata (like `[[node]]...[[/node]]`) leaks into the conversation context, causing models to mimic these tags and pollute logs. The expected behavior is for only user and assistant messages to be included in the LLM context, but this filtering is currently broken in v1.11.2 [[source](https://github.com/langgenius/dify/issues/31022)]. For missing conversation history in logs, this is partly due to frontend state/query invalidation—after switching conversations, the UI may not reload messages unless you refresh or switch again. This is a known bug in the frontend logic (see issues #29820, #31422, #30378), not a deployment or config error [[source](https://github.com/langgenius/dify/issues/30378)]. There are no config changes or workarounds that fully resolve these issues in v1.11.2. Upgrading to a newer version (v1.11.4 or later) is recommended, as several related bugs have been fixed there. In the meantime, you can try manually refreshing the page or toggling conversations to restore history display, and if you need to patch the node metadata leak, you would need to sanitize message content in the backend before it reaches the LLM [[source](https://github.com/langgenius/dify/issues/31022)]. If you need to keep using v1.11.2, enabling memory features in your agent.yaml and adjusting token limits may help with memory node consistency, but won't fix the frontend or logging bugs. There are no automated scripts deleting logs, so your data should remain in the database unless affected by a bug or manual operation [[source](https://github.com/langgenius/dify/issues/31422)]. <!-- 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/5708f78e-940c-4773-881b-6294d7e0e8e6?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/5708f78e-940c-4773-881b-6294d7e0e8e6?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/5708f78e-940c-4773-881b-6294d7e0e8e6?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/5708f78e-940c-4773-881b-6294d7e0e8e6?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/5708f78e-940c-4773-881b-6294d7e0e8e6?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/5708f78e-940c-4773-881b-6294d7e0e8e6?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/5708f78e-940c-4773-881b-6294d7e0e8e6?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%20are%20known%20issues%20in%20Dify%20v1.11.2%20%28self-hosted%29%20that%20match%20what%20you%27re%20seeing%3A%20React%20mode%20can%20output%20unstable%20or%20excessive%20JSON%20for%20tool%20calls%2C%20and%20memory%20nodes%20may%20appear%20or%20disappear%20inconsistently.%20This%20instability%20is%20linked%20to%20recent%20changes%20in%20how%20conversation%20variables%20are%20persisted%20and%20how%20logs%20are%20structured%2C%20as%20well%20as%20a%20bug%20where%20internal%20node%20metadata%20%28like%20%60%5B%5Bnode%5D%5D...%5B%5B/node%5D%5D%60%29%20leaks%20into%20the%20conversation%20context%2C%20causing%20models%20to%20mimic%20these%20tags%20and%20pollute%20logs.%20The%20expected%20behavior%20is%20for%20only%20user%20and%20assistant%20messages%20to%20be%20included%20in%20the%20LLM%20context%2C%20but%20this%20filtering%20is%20currently%20broken%20in%20v1.11.2%20%5B%5Bsource%5D%28https%3A//github.com/langgenius/dify/issues/31022%29%5D.%0A%0AFor%20missing%20conversation%20history%20in%20logs%2C%20this%20is%20partly%20due%20to%20frontend%20state/query%20invalidation%E2%80%94after%20switching%20conversations%2C%20the%20UI%20may%20not%20reload%20messages%20unless%20you%20refresh%20or%20switch%20again.%20This%20is%20a%20known%20bug%20in%20the%20frontend%20logic%20%28see%20issues%20%2329820%2C%20%2331422%2C%20%2330378%29%2C%20not%20a%20deployment%20or%20config%20error%20%5B%5Bsource%5D%28https%3A//github.com/langgenius/dify/issues/30378%29%5D.%0A%0AThere%20are%20no%20config%20changes%20or%20workarounds%20that%20fully%20resolve%20these%20issues%20in%20v1.11.2.%20Upgrading%20to%20a%20newer%20version%20%28v1.11.4%20or%20later%29%20is%20recommended%2C%20as%20several%20related%20bugs%20have%20been%20fixed%20there.%20In%20the%20meantime%2C%20you%20can%20try%20manually%20refreshing%20the%20page%20or%20toggling%20conversations%20to%20restore%20history%20display%2C%20and%20if%20you%20need%20to%20patch%20the%20node%20metadata%20leak%2C%20you%20would%20need%20to%20sanitize%20message%20content%20in%20the%20backend%20before%20it%20reaches%20the%20LLM%20%5B%5Bsource%5D%28https%3A//github.com/langgenius/dify/issues/31022%29%5D.%0A%0AIf%20you%20need%20to%20keep%20using%20v1.11.2%2C%20enabling%20memory%20features%20in%20your%20agent.yaml%20and%20adjusting%20token%20limits%20may%20help%20with%20memory%20node%20consistency%2C%20but%20won%27t%20fix%20the%20frontend%20or%20logging%20bugs.%20There%20are%20no%20automated%20scripts%20deleting%20logs%2C%20so%20your%20data%20should%20remain%20in%20the%20database%20unless%20affected%20by%20a%20bug%20or%20manual%20operation%20%5B%5Bsource%5D%28https%3A//github.com/langgenius/dify/issues/31422%29%5D.)&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/31532)
Author
Owner

@xiaotang-12-ops commented on GitHub (Jan 26, 2026):

Dify v1.11.2(自托管)中已知存在与你看到的情况相符的问题:React 模式可能输出不稳定或过多的 JSON 来调用工具,内存节点的出现或消失也可能不一致。这种不稳定性与近期对话变量持久化和日志结构的变化有关,同时也与内部节点元数据(如)泄漏到对话上下文中,导致模型模仿这些标签并污染日志有关。预期行为是仅包含用户和助手消息,但该过滤在 v1.11.2 [来源]中已被破坏。[[node]]...[[/node]]

日志中缺少对话历史,部分原因是前端状态/查询失效——切换对话后,除非刷新或再次切换,否则UI可能无法重新加载消息。这是前端逻辑中的已知错误(参见问题 #29820#31422#30378),而非部署或配置错误[来源]。

v1.11.2 中没有任何配置更改或变通方法能完全解决这些问题。建议升级到更新版本(v1.11.4或更高版本),因为相关漏洞已修复。与此同时,你可以尝试手动刷新页面或切换对话以恢复历史显示,如果需要修补节点元数据泄露,你需要在消息内容到达LLM [代码]之前在后端进行净化。

如果你需要继续使用v1.11.2,启用agent.yaml中的内存功能并调整令牌限制可能有助于内存节点一致性,但无法解决前端或日志错误。没有自动脚本删除日志,因此除非出现错误或手动作,否则你的数据应保留在数据库中[来源]。

回复时,只需提及@dosu

我表现得怎么样?很好 |无关紧要 |错误 |冗长 |幻觉 |报告 🐛 |其他

与Dosu聊天 光标打开 加入Discord 分享到X平台

It seems you didn’t get what I meant. What I’m saying is that even though I’ve enabled the memory feature, the conversation actually has no memory at all. I then checked the logs and found there aren’t even any conversation records in them — this doesn’t seem to align with what you said earlier.

@xiaotang-12-ops commented on GitHub (Jan 26, 2026): > Dify v1.11.2(自托管)中已知存在与你看到的情况相符的问题:React 模式可能输出不稳定或过多的 JSON 来调用工具,内存节点的出现或消失也可能不一致。这种不稳定性与近期对话变量持久化和日志结构的变化有关,同时也与内部节点元数据(如)泄漏到对话上下文中,导致模型模仿这些标签并污染日志有关。预期行为是仅包含用户和助手消息,但该过滤在 v1.11.2 [[来源](https://github.com/langgenius/dify/issues/31022)]中已被破坏。`[[node]]...[[/node]]` > > 日志中缺少对话历史,部分原因是前端状态/查询失效——切换对话后,除非刷新或再次切换,否则UI可能无法重新加载消息。这是前端逻辑中的已知错误(参见问题 [#29820](https://github.com/langgenius/dify/issues/29820)、[#31422](https://github.com/langgenius/dify/issues/31422)、[#30378](https://github.com/langgenius/dify/issues/30378)),而非部署或配置错误[[来源](https://github.com/langgenius/dify/issues/30378)]。 > > v1.11.2 中没有任何配置更改或变通方法能完全解决这些问题。建议升级到更新版本(v1.11.4或更高版本),因为相关漏洞已修复。与此同时,你可以尝试手动刷新页面或切换对话以恢复历史显示,如果需要修补节点元数据泄露,你需要在消息内容到达LLM [[源](https://github.com/langgenius/dify/issues/31022)代码]之前在后端进行净化。 > > 如果你需要继续使用v1.11.2,启用agent.yaml中的内存功能并调整令牌限制可能有助于内存节点一致性,但无法解决前端或日志错误。没有自动脚本删除日志,因此除非出现错误或手动作,否则你的数据应保留在数据库中[[来源](https://github.com/langgenius/dify/issues/31422)]。 > > _回复时,只需提及[@dosu](https://go.dosu.dev/dosubot)。_ > > 我表现得怎么样?[很好](https://app.dosu.dev/response-feedback/5708f78e-940c-4773-881b-6294d7e0e8e6?feedback_type=great_response) |[无关紧要](https://app.dosu.dev/response-feedback/5708f78e-940c-4773-881b-6294d7e0e8e6?feedback_type=irrelevant_answer) |[错误](https://app.dosu.dev/response-feedback/5708f78e-940c-4773-881b-6294d7e0e8e6?feedback_type=incorrect_sources) |[冗长](https://app.dosu.dev/response-feedback/5708f78e-940c-4773-881b-6294d7e0e8e6?feedback_type=too_verbose) |[幻觉](https://app.dosu.dev/response-feedback/5708f78e-940c-4773-881b-6294d7e0e8e6?feedback_type=hallucination) |[报告 🐛](https://app.dosu.dev/response-feedback/5708f78e-940c-4773-881b-6294d7e0e8e6?feedback_type=bug_report) |[其他](https://app.dosu.dev/response-feedback/5708f78e-940c-4773-881b-6294d7e0e8e6?feedback_type=other) > > [![与Dosu聊天](https://camo.githubusercontent.com/7c571478962a6b8a5d47cac74b6824c75e4f6731bba52377e6007f9150462923/68747470733a2f2f646f73752e6465762f646f73752d636861742d62616467652e737667)](https://app.dosu.dev/6088a4f4-073a-43f3-b3d4-4f06fb0c05a0/ask?utm_source=github) [![光标打开](https://camo.githubusercontent.com/bdf7dbded65ee585887f47e5fd6fa099ea0933088b4b03d02e83b4def50154d4/68747470733a2f2f646f73752e6465762f646f73752d696e2d637572736f722e737667)](https://cursor.com/link/prompt?text=There%20are%20known%20issues%20in%20Dify%20v1.11.2%20%28self-hosted%29%20that%20match%20what%20you%27re%20seeing%3A%20React%20mode%20can%20output%20unstable%20or%20excessive%20JSON%20for%20tool%20calls%2C%20and%20memory%20nodes%20may%20appear%20or%20disappear%20inconsistently.%20This%20instability%20is%20linked%20to%20recent%20changes%20in%20how%20conversation%20variables%20are%20persisted%20and%20how%20logs%20are%20structured%2C%20as%20well%20as%20a%20bug%20where%20internal%20node%20metadata%20%28like%20%60%5B%5Bnode%5D%5D...%5B%5B/node%5D%5D%60%29%20leaks%20into%20the%20conversation%20context%2C%20causing%20models%20to%20mimic%20these%20tags%20and%20pollute%20logs.%20The%20expected%20behavior%20is%20for%20only%20user%20and%20assistant%20messages%20to%20be%20included%20in%20the%20LLM%20context%2C%20but%20this%20filtering%20is%20currently%20broken%20in%20v1.11.2%20%5B%5Bsource%5D%28https%3A//github.com/langgenius/dify/issues/31022%29%5D.%0A%0AFor%20missing%20conversation%20history%20in%20logs%2C%20this%20is%20partly%20due%20to%20frontend%20state/query%20invalidation%E2%80%94after%20switching%20conversations%2C%20the%20UI%20may%20not%20reload%20messages%20unless%20you%20refresh%20or%20switch%20again.%20This%20is%20a%20known%20bug%20in%20the%20frontend%20logic%20%28see%20issues%20%2329820%2C%20%2331422%2C%20%2330378%29%2C%20not%20a%20deployment%20or%20config%20error%20%5B%5Bsource%5D%28https%3A//github.com/langgenius/dify/issues/30378%29%5D.%0A%0AThere%20are%20no%20config%20changes%20or%20workarounds%20that%20fully%20resolve%20these%20issues%20in%20v1.11.2.%20Upgrading%20to%20a%20newer%20version%20%28v1.11.4%20or%20later%29%20is%20recommended%2C%20as%20several%20related%20bugs%20have%20been%20fixed%20there.%20In%20the%20meantime%2C%20you%20can%20try%20manually%20refreshing%20the%20page%20or%20toggling%20conversations%20to%20restore%20history%20display%2C%20and%20if%20you%20need%20to%20patch%20the%20node%20metadata%20leak%2C%20you%20would%20need%20to%20sanitize%20message%20content%20in%20the%20backend%20before%20it%20reaches%20the%20LLM%20%5B%5Bsource%5D%28https%3A//github.com/langgenius/dify/issues/31022%29%5D.%0A%0AIf%20you%20need%20to%20keep%20using%20v1.11.2%2C%20enabling%20memory%20features%20in%20your%20agent.yaml%20and%20adjusting%20token%20limits%20may%20help%20with%20memory%20node%20consistency%2C%20but%20won%27t%20fix%20the%20frontend%20or%20logging%20bugs.%20There%20are%20no%20automated%20scripts%20deleting%20logs%2C%20so%20your%20data%20should%20remain%20in%20the%20database%20unless%20affected%20by%20a%20bug%20or%20manual%20operation%20%5B%5Bsource%5D%28https%3A//github.com/langgenius/dify/issues/31422%29%5D.) [![加入Discord](https://camo.githubusercontent.com/7d2066700925db1e370d956834f9ea0e5bc92cecbe84963fbd2a363e45091b4e/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f6a6f696e2d3538363546323f6c6f676f3d646973636f7264266c6f676f436f6c6f723d7768697465266c6162656c3d)](https://go.dosu.dev/discord-bot) [![分享到X平台](https://camo.githubusercontent.com/a8bd7f3fcf3f5e3bd124eee9ae50ae2ac17b40971726665ac2121d48f9aee155/68747470733a2f2f696d672e736869656c64732e696f2f62616467652f582d73686172652d626c61636b)](https://twitter.com/intent/tweet?text=%40dosu_ai%20helped%20me%20solve%20this%20issue!&url=https%3A//github.com/langgenius/dify/issues/31532) It seems you didn’t get what I meant. What I’m saying is that even though I’ve enabled the memory feature, the conversation actually has no memory at all. I then checked the logs and found there aren’t even any conversation records in them — this doesn’t seem to align with what you said earlier.
Author
Owner

@dosubot[bot] commented on GitHub (Jan 26, 2026):

The complete absence of conversation records and memory—even with the memory feature enabled—is not an expected or documented bug in Dify v1.11.2. This usually points to a deeper backend or database issue, not just frontend or configuration problems.

Conversation memory and logs depend on messages being successfully written to the database. If there are no records, it's likely due to failures before message rows are created, such as database connection errors, transaction failures, or exceptions in the request pipeline—not normal UI bugs or config issues. There is no code or config in v1.11.2 that disables message persistence by default, and logs are not deleted automatically unless affected by a bug or manual operation [source].

To troubleshoot:

  • Query your database directly (messages and conversations tables) to see if any records are being created for new chats.
  • Check backend logs for errors during message creation or conversation handling (look for DB connection errors, transaction failures, or unhandled exceptions).
  • Make sure your backend service has write access to the database and that the DB is not in a read-only or error state. A recent fix addressed DB engine initialization issues that could block all DB operations [source].
  • Ensure your agent.yaml and other config files are correctly mounted and loaded in Docker, and that no environment variables are overriding expected behavior.
  • If you use custom plugins or have modified the code, try reverting to a clean v1.11.2 deployment to rule out side effects.
  • Optionally, enable debug logging to capture more detailed traces of the message creation pipeline.

If you can share any error logs or DB query results, I can help interpret them. The relevant code paths for tracing these issues are the Conversation and Message ORM models, the ChatAppRunner, and the queue manager.

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 (Jan 26, 2026): <!-- Answer --> The complete absence of conversation records and memory—even with the memory feature enabled—is not an expected or documented bug in Dify v1.11.2. This usually points to a deeper backend or database issue, not just frontend or configuration problems. Conversation memory and logs depend on messages being successfully written to the database. If there are no records, it's likely due to failures before message rows are created, such as database connection errors, transaction failures, or exceptions in the request pipeline—not normal UI bugs or config issues. There is no code or config in v1.11.2 that disables message persistence by default, and logs are not deleted automatically unless affected by a bug or manual operation [[source]](https://github.com/langgenius/dify/blob/8724ba04aa394edccea67383aefe035c85fe6b55/api/models/model.py#L703-L1400). To troubleshoot: - Query your database directly (messages and conversations tables) to see if any records are being created for new chats. - Check backend logs for errors during message creation or conversation handling (look for DB connection errors, transaction failures, or unhandled exceptions). - Make sure your backend service has write access to the database and that the DB is not in a read-only or error state. A recent fix addressed DB engine initialization issues that could block all DB operations [[source]](https://github.com/langgenius/dify/pull/30541). - Ensure your agent.yaml and other config files are correctly mounted and loaded in Docker, and that no environment variables are overriding expected behavior. - If you use custom plugins or have modified the code, try reverting to a clean v1.11.2 deployment to rule out side effects. - Optionally, enable debug logging to capture more detailed traces of the message creation pipeline. If you can share any error logs or DB query results, I can help interpret them. The relevant code paths for tracing these issues are the Conversation and Message ORM models, the ChatAppRunner, and the queue manager. <!-- 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/e9acac1f-627c-4775-ac82-676a50f73f72?feedback_type=great_response) | [Irrelevant](https://app.dosu.dev/response-feedback/e9acac1f-627c-4775-ac82-676a50f73f72?feedback_type=irrelevant_answer) | [Incorrect](https://app.dosu.dev/response-feedback/e9acac1f-627c-4775-ac82-676a50f73f72?feedback_type=incorrect_sources) | [Verbose](https://app.dosu.dev/response-feedback/e9acac1f-627c-4775-ac82-676a50f73f72?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/e9acac1f-627c-4775-ac82-676a50f73f72?feedback_type=hallucination) | [Report 🐛](https://app.dosu.dev/response-feedback/e9acac1f-627c-4775-ac82-676a50f73f72?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/e9acac1f-627c-4775-ac82-676a50f73f72?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%20complete%20absence%20of%20conversation%20records%20and%20memory%E2%80%94even%20with%20the%20memory%20feature%20enabled%E2%80%94is%20not%20an%20expected%20or%20documented%20bug%20in%20Dify%20v1.11.2.%20This%20usually%20points%20to%20a%20deeper%20backend%20or%20database%20issue%2C%20not%20just%20frontend%20or%20configuration%20problems.%0A%0AConversation%20memory%20and%20logs%20depend%20on%20messages%20being%20successfully%20written%20to%20the%20database.%20If%20there%20are%20no%20records%2C%20it%27s%20likely%20due%20to%20failures%20before%20message%20rows%20are%20created%2C%20such%20as%20database%20connection%20errors%2C%20transaction%20failures%2C%20or%20exceptions%20in%20the%20request%20pipeline%E2%80%94not%20normal%20UI%20bugs%20or%20config%20issues.%20There%20is%20no%20code%20or%20config%20in%20v1.11.2%20that%20disables%20message%20persistence%20by%20default%2C%20and%20logs%20are%20not%20deleted%20automatically%20unless%20affected%20by%20a%20bug%20or%20manual%20operation%20%5B%5Bsource%5D%5D%28https%3A//github.com/langgenius/dify/blob/8724ba04aa394edccea67383aefe035c85fe6b55/api/models/model.py%23L703-L1400%29.%0A%0ATo%20troubleshoot%3A%0A-%20Query%20your%20database%20directly%20%28messages%20and%20conversations%20tables%29%20to%20see%20if%20any%20records%20are%20being%20created%20for%20new%20chats.%0A-%20Check%20backend%20logs%20for%20errors%20during%20message%20creation%20or%20conversation%20handling%20%28look%20for%20DB%20connection%20errors%2C%20transaction%20failures%2C%20or%20unhandled%20exceptions%29.%0A-%20Make%20sure%20your%20backend%20service%20has%20write%20access%20to%20the%20database%20and%20that%20the%20DB%20is%20not%20in%20a%20read-only%20or%20error%20state.%20A%20recent%20fix%20addressed%20DB%20engine%20initialization%20issues%20that%20could%20block%20all%20DB%20operations%20%5B%5Bsource%5D%5D%28https%3A//github.com/langgenius/dify/pull/30541%29.%0A-%20Ensure%20your%20agent.yaml%20and%20other%20config%20files%20are%20correctly%20mounted%20and%20loaded%20in%20Docker%2C%20and%20that%20no%20environment%20variables%20are%20overriding%20expected%20behavior.%0A-%20If%20you%20use%20custom%20plugins%20or%20have%20modified%20the%20code%2C%20try%20reverting%20to%20a%20clean%20v1.11.2%20deployment%20to%20rule%20out%20side%20effects.%0A-%20Optionally%2C%20enable%20debug%20logging%20to%20capture%20more%20detailed%20traces%20of%20the%20message%20creation%20pipeline.%0A%0AIf%20you%20can%20share%20any%20error%20logs%20or%20DB%20query%20results%2C%20I%20can%20help%20interpret%20them.%20The%20relevant%20code%20paths%20for%20tracing%20these%20issues%20are%20the%20Conversation%20and%20Message%20ORM%20models%2C%20the%20ChatAppRunner%2C%20and%20the%20queue%20manager.)&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/31532)
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: langgenius/dify#21899