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

Markdown fails to render subsequent <think> blocks in multi-node Chatflows #13078

New Issue
Closed
opened 2026-02-21 19:10:27 -05:00 by yindo · 2 comments
yindo commented 2026-02-21 19:10:27 -05:00
Owner
Copy Link
Copy Source

Originally created by @xuzijie1995 on GitHub (Apr 17, 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

1.2.0

Cloud or Self Hosted

Self Hosted (Docker)

Steps to reproduce

  1. Create a new application using the Chatflow mode.
  2. Drag and drop at least two Large Language Model nodes onto the canvas.
  3. Connect the nodes sequentially: Start -> LLM Node 1 -> Answer 1 -> LLM Node 2 -> Answer 2 -> End.
  4. Go to the "Debug and Preview" panel or deploy the application and use the WebApp.
  5. Run the Chatflow by sending an initial message.
  6. Observe the output generated in the chat interface.
Image

✔️ Expected Behavior

Both LLM nodes should produce distinct, independently expandable "Thinking..." sections in the chat interface. Each section should correspond to the <think>...</think> output of its respective LLM node and correctly display the content generated within the tags.

Image

❌ Actual Behavior

Only the first <think>...</think> block (from LLM Node 1 in the steps above) is correctly rendered as an expandable "Thinking..." section.

The subsequent <think>...</think> block (from LLM Node 2) is not rendered correctly. Its content might appear as plain text, or the tags <think> and </think> might be visible directly in the output, instead of being transformed into the expected UI component.

Cause & Proposed Solution:

The issue seems to stem from the preprocessThinkTag function in web/app/components/base/markdown.tsx. The original implementation used string.replace() which only replaces the first occurrence of the opening and closing tags.

A proposed fix is to modify this function to use regular expressions with the global (g) flag to ensure all occurrences of <think>\n and \n</think> are replaced:

Image
Originally created by @xuzijie1995 on GitHub (Apr 17, 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 1.2.0 ### Cloud or Self Hosted Self Hosted (Docker) ### Steps to reproduce 1. Create a new application using the **Chatflow** mode. 2. Drag and drop at least two **Large Language Model** nodes onto the canvas. 3. Connect the nodes sequentially: **Start** -> **LLM Node 1** -> **Answer 1** -> **LLM Node 2** -> **Answer 2** -> **End**. 3. Go to the **"Debug and Preview"** panel or deploy the application and use the WebApp. 4. Run the Chatflow by sending an initial message. 5. Observe the output generated in the chat interface. <img width="941" alt="Image" src="https://github.com/user-attachments/assets/a1dea57f-0430-49da-a61b-afdacfef8b00" /> ### ✔️ Expected Behavior Both LLM nodes should produce distinct, independently expandable "Thinking..." sections in the chat interface. Each section should correspond to the `<think>...</think>` output of its respective LLM node and correctly display the content generated within the tags. <img width="469" alt="Image" src="https://github.com/user-attachments/assets/45c471b3-7378-47c0-9287-b05ca2cfa408" /> ### ❌ Actual Behavior Only the *first* `<think>...</think>` block (from LLM Node 1 in the steps above) is correctly rendered as an expandable "Thinking..." section. The subsequent `<think>...</think>` block (from LLM Node 2) is **not** rendered correctly. Its content might appear as plain text, or the tags `<think>` and `</think>` might be visible directly in the output, instead of being transformed into the expected UI component. **Cause & Proposed Solution:** The issue seems to stem from the `preprocessThinkTag` function in `web/app/components/base/markdown.tsx`. The original implementation used `string.replace()` which only replaces the first occurrence of the opening and closing tags. A proposed fix is to modify this function to use regular expressions with the global (`g`) flag to ensure *all* occurrences of `<think>\n` and `\n</think>` are replaced: <img width="457" alt="Image" src="https://github.com/user-attachments/assets/7d5221cc-61e6-4951-805f-0206dbfd4c7d" />
yindo added the 🐞 bug label 2026-02-21 19:10:27 -05:00
yindo closed this issue 2026-02-21 19:10:27 -05:00
yindo commented 2026-02-21 19:10:28 -05:00
Author
Owner
Copy Link
Copy Source

@dosubot[bot] commented on GitHub (Apr 17, 2025):

I found a similar unsolved discussion regarding the issue where multiple <think> tags in the response cannot all be rendered properly [1]. The problem seems to be related to the preprocessThinkTag function, which currently uses string.replace() to transform the tags. This method only replaces the first occurrence of the tags, which is why subsequent <think> blocks are not rendered correctly.

To address this, you can modify the preprocessThinkTag function to use regular expressions with the global (g) flag. This will ensure that all occurrences of <think>\n and \n</think> are replaced, allowing each <think> block to be rendered as expected.

To continue talking to Dosu, mention @dosu.

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

@dosubot[bot] commented on GitHub (Apr 17, 2025): <!-- Answer --> I found a similar unsolved discussion regarding the issue where multiple `<think>` tags in the response cannot all be rendered properly <sup>[[1]](https://github.com/langgenius/dify/discussions/16768)</sup>. The problem seems to be related to the `preprocessThinkTag` function, which currently uses `string.replace()` to transform the tags. This method only replaces the first occurrence of the tags, which is why subsequent `<think>` blocks are not rendered correctly. To address this, you can modify the `preprocessThinkTag` function to use regular expressions with the global (`g`) flag. This will ensure that all occurrences of `<think>\n` and `\n</think>` are replaced, allowing each `<think>` block to be rendered as expected. <!-- 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/45f28dd9-60b5-42cd-a37f-951a8c5a8d93?feedback_type=great_response) | [Irrelevant Answer](https://app.dosu.dev/response-feedback/45f28dd9-60b5-42cd-a37f-951a8c5a8d93?feedback_type=irrelevant_answer) | [Incorrect Sources](https://app.dosu.dev/response-feedback/45f28dd9-60b5-42cd-a37f-951a8c5a8d93?feedback_type=incorrect_sources) | [Too Verbose](https://app.dosu.dev/response-feedback/45f28dd9-60b5-42cd-a37f-951a8c5a8d93?feedback_type=too_verbose) | [Hallucination](https://app.dosu.dev/response-feedback/45f28dd9-60b5-42cd-a37f-951a8c5a8d93?feedback_type=hallucination) | [Bug Report](https://app.dosu.dev/response-feedback/45f28dd9-60b5-42cd-a37f-951a8c5a8d93?feedback_type=bug_report) | [Other](https://app.dosu.dev/response-feedback/45f28dd9-60b5-42cd-a37f-951a8c5a8d93?feedback_type=other)</sup>
yindo commented 2026-02-21 19:10:28 -05:00
Author
Owner
Copy Link
Copy Source

@xuzijie1995 commented on GitHub (Apr 17, 2025):

FYI
https://github.com/langgenius/dify/pull/18310

@xuzijie1995 commented on GitHub (Apr 17, 2025): FYI https://github.com/langgenius/dify/pull/18310
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 🐞 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#13078
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?