fix: gpt-oss thinking block

[urmauur]

Describe Your Changes

This pull request updates the handling and rendering of "thinking" or reasoning content in the app to support both legacy <think>...</think> tags and the newer channel/message marker format. The changes ensure that both formats are detected, extracted, and displayed consistently, improving compatibility and maintainability.

Improvements to "thinking" content detection and extraction:

• Enhanced the logic in ThinkingBlock.tsx to detect both <think>...</think> and <|channel|>analysis<|message|>...<|start|>assistant<|channel|>final<|message|> formats, and updated the loading state to reflect either in-progress format.
• Added a new extractThinkingContent function in ThinkingBlock.tsx to consistently remove all "thinking" and channel/message markers from the text, ensuring only the relevant content is rendered.
• Updated the rendering logic to use the extracted thinking content when displaying markdown, preventing display of raw tags or markers.

Consistent segmentation of message content:

• Modified ThreadContent.tsx to segment messages into reasoning and main text portions for both the <think>...</think> and channel/message marker formats, supporting both in-progress and completed states. This ensures that reasoning content is displayed separately and consistently, regardless of the format used.

Fixes Issues

• Closes #
• Closes #

Self Checklist

• Added relevant comments, esp in complex areas
• Updated docs (for bug fixes / features)
• Created issues for follow-up changes or refactoring needed

---

Important

Enhances 'thinking' content handling in ThinkingBlock.tsx and ThreadContent.tsx to support both legacy and new formats, ensuring consistent detection, extraction, and rendering.

• Behavior:
  • ThinkingBlock.tsx: Detects both <think>...</think> and <|channel|>analysis<|message|>...<|start|>assistant<|channel|>final<|message|> formats for 'thinking' content.
  • extractThinkingContent function added to remove 'thinking' and channel/message markers, ensuring only relevant content is rendered.
  • Updated rendering logic to use extracted content, preventing raw tag display.
• Segmentation:
  • ThreadContent.tsx: Segments messages into reasoning and main text for both formats, supporting in-progress and completed states.
  • Ensures consistent display of reasoning content regardless of format.

^{This description was created by for cae9053. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to cae9053 in 1 minute and 41 seconds. Click for details.

• Reviewed 94 lines of code in 2 files
• Skipped 0 files when reviewing.
• Skipped posting 4 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. web-app/src/containers/ThinkingBlock.tsx:44

• Draft comment:
  Consider consolidating and documenting the multiple regex replacements in extractThinkingContent for clarity and maintainability, as they handle similar marker patterns.
• Reason this comment was not posted:
  Confidence changes required: 33% <= threshold 50% None

2. web-app/src/containers/ThinkingBlock.tsx:48

• Draft comment:
  Review the need for both replacements for '<|start|>assistant<|channel|>final<|message|>' and 'assistant<|channel|>final<|message|>' as they might be redundant.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% Without knowing the exact format of the input text and all possible variations, it's hard to be certain if both replacements are truly redundant. The author might have included both patterns to handle different message formats. The comment is speculative and doesn't provide clear evidence that this is actually a problem. I might be missing some edge cases where both replacements are actually necessary. The author might have good reasons for handling both patterns separately. Even if there are edge cases, the comment is phrased as a suggestion to "review" rather than providing concrete evidence of an issue or a clear action item. The comment should be deleted as it's speculative and doesn't provide strong evidence that there's actually a problem to fix.

3. web-app/src/containers/ThreadContent.tsx:172

• Draft comment:
  The logic for detecting and segmenting thinking markers is duplicated here. Consider refactoring shared extraction logic to maintain consistency with ThinkingBlock.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable: usefulness confidence = 10% vs. threshold = 50% While the code does handle thinking marker extraction, I cannot verify if this logic is actually duplicated in ThinkingBlock since I don't have access to that file. The comment makes an assumption about duplication without providing concrete evidence. Making architectural suggestions without full context could lead to incorrect recommendations. I could be wrong about dismissing this - maybe there is obvious duplication that an experienced developer would recognize. The thinking marker formats look like they could be standardized. Without seeing the ThinkingBlock implementation, I cannot verify the duplication claim. Making assumptions about code in other files violates the cross-file issues rule. The comment should be removed since it makes claims about code duplication without sufficient evidence and requires examining other files to verify.

4. web-app/src/containers/ThreadContent.tsx:337

• Draft comment:
  Using .replace('', '') on textSegment may not fully clean all leftover markers. Consider applying a comprehensive cleanup similar to extractThinkingContent.
• Reason this comment was not posted:
  Comment was not on a location in the diff, so it can't be submitted as a review comment.

Workflow ID: wflow_ZgUDcpKkit6dv9Jn

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[github-actions]

Barecheck - Code coverage report

Total: 33.15%

Your code coverage diff: -0.04% ▾

Uncovered files and lines

File	Lines
web-app/src/containers/ThinkingBlock.tsx	1-5, 18-27, 29-32, 34-41, 44-54, 56-57, 59-62, 64-67, 69-71, 73, 75-79, 81-84, 86-87, 89, 91
web-app/src/containers/ThreadContent.tsx	2-4, 12-18, 27-29, 34-35, 37, 39-41, 43-45, 47-51, 53-56, 58-62, 64-71, 73, 75, 77-80, 83-85, 87-91, 93-114, 116-121, 123-129, 131-136, 138, 141-143, 152-153, 156-159, 161-165, 167-170, 172, 174-175, 177, 180-187, 190-197, 199-200, 202-203, 205, 207-218, 220-232, 234-237, 239-244, 246-250, 252, 256-286, 288-296, 298-309, 312-319, 321-322, 325-330, 332-333, 336-339, 341-350, 352-355, 357-362, 364-374, 376-379, 381-389, 391-437, 439-444, 446-452, 454, 456-465, 467, 470-478, 480-481, 483-484

[louis-jan]

LGTM (refactor later)

[mpetruc]

Using 0.6.9-1535 (nightly). Thinking and final response from gpt-oss-120b still crammed inside the "Thought" block:

Thought
<|channel|>analysis<|message|>We need to sort given letters alphabetically. The letters: f, d, t, v, u, m, o, i, s. Alphabetical order: d, f, i, m, o, s, t, u, v? Wait alphabetical order: a b c d e f g h i j k l m n o p q r s t u v w x y z. So order: d (4), f (6), i (9), m (13), o (15), s (19), t (20), u (21), v (22). Yes. Provide answer.<|end|>The letters in alphabetical order are:

**d  f  i  m  o  s  t  u  v**