fix(ui): reset thinking time display when new session starts

[GeorgeDong32]

What this PR does

Before this PR:
When sending a prompt with a thinking model, the displayed thinking time counter doesn't start from 0s on subsequent prompts. Instead, it accumulates from the previous thinking session's value because the displayTime state in ThinkingTimeSeconds component is not reset when a new thinking session starts.

After this PR:
Added logic to reset displayTime to 0 when isThinking becomes true and blockThinkingTime === 0 (indicating a new thinking session). This ensures the thinking time counter starts fresh from 0s for each new prompt.

Fixes #13449

Why we need it and why it was done in this way

Root cause: The ThinkingTimeSeconds component uses useState to track displayTime, which is only initialized once when the component mounts. When React reuses the component instance for a new thinking block, the previous displayTime value persists, causing the timer to accumulate from the old value.

The fix: Added a conditional reset in the useEffect that handles the isThinking state change:

if (isThinking) {
  // Reset displayTime when starting new thinking session
  if (blockThinkingTime === 0) {
    setDisplayTime(0)
  }
  // ...
}

Tradeoffs made:

• Minimal change to avoid disrupting existing timer logic
• Reset only when blockThinkingTime === 0 to preserve behavior for resumed/in-progress sessions

Alternatives considered:

• Using a useRef to track timer start time: rejected as it would require more extensive refactoring
• Adding a unique session ID dependency: rejected as unnecessary complexity for this bug fix

Breaking changes

None. This is a bug fix that only affects the display behavior of the thinking time counter.

Special notes for your reviewer

• The fix targets the specific case where a new thinking session starts (isThinking transitions from false to true)
• The condition blockThinkingTime === 0 ensures we only reset for genuinely new sessions, not resumed ones
• Verified with Vercel React Best Practices - follows rerender-dependencies and rerender-functional-setstate guidelines

Checklist

• PR: The PR description is expressive enough and will help future contributors
• Code: Write code that humans can understand and Keep it simple
• Refactor: You have left the code cleaner than you found it (Boy Scout Rule)
• Upgrade: Impact of this change on upgrade flows was considered and addressed if required
• Documentation: A user-guide update was considered and is present (link) or not required. Check this only when the PR introduces or changes a user-facing feature or behavior.
• Self-review: I have reviewed my own code (e.g., via /gh-pr-review, gh pr diff, or GitHub UI) before requesting review from others

Release note

Fixed thinking time display bug where the timer would accumulate from previous sessions instead of starting from 0s for each new prompt.

[cherry-ai-bot]

Reviewed the fix and the added regression test. The reset condition is scoped narrowly to genuinely new thinking sessions (isThinking with blockThinkingTime === 0), so it addresses the stale display-time carryover without changing the resumed-session path. I don't see new blocking issues in the current revision. LGTM.

[EurFelux]

But how could this happen? Did you reproduce it? If a new thinking session is started, it should create a new ThinkingBlock.

[EurFelux]

When React reuses the component instance for a new thinking block, the previous displayTime value persists, causing the timer to accumulate from the old value.

It's not how react's function component works. Component is a function, and concrete component has its independent state.

[EurFelux]

Note

This issue/comment/review was translated by Claude.

Considering that the component's responsibility is only to render the actual data in the block, I think the issue might be caused by not correctly resetting thinkingStartTime somewhere upstream when handling the thinking block.

---

Original Content

考虑到组件的职责仅是渲染 block 中实际的数据，我认为可能是在处理 thinking block 的上游的某处没有正确地重置 thinkingStartTIme 导致了此问题。

[EurFelux]

Note

This review was translated by Claude.

Based on the previous analysis, I don't think we should approach this from the component level. Please look for the real root cause.

---

Original Content

基于此前的分析，我认为不应该从组件上下手，请寻找真正的根因。

[GeorgeDong32]

Based on the previous analysis, I don't think we should approach this from the component level. Please look for the real root cause.

Note

This issue/comment/review was translated by Claude.

OK, I'll try to reproduce this issue later

---

Original Content

OK，我晚点试试复现这个问题