[Bug]: Assistant message hover timestamp missing while a command is still running
维护者通常 1 天内回复
评估
- 难度
- 2/5
- 预计耗时
- 1-3 小时
- 新手友好度
- 87/100
- Issue 类型
- 缺陷
- 描述清晰度
- 描述清楚
- 活跃度
- 活跃
- 技术栈
- react, typescript
- 领域
- frontend
调研方向
先查看 apps/web/src/components/chat/MessagesTimeline.logic.ts 中的 showAssistantMeta 和 attachTrailingToolGroupsToAssistant,然后检查 apps/web/src/components/chat/TimelineAssistantRows.tsx 中 AssistantMessageMeta 如何渲染时间戳。用正在执行的命令重现问题,并与已完成的工具组进行比较。完成的标准是:命令运行时,末尾的 assistant 消息显示悬停时间戳;而在流式传输期间不显示该时间戳。
由索引模型根据 Issue 内容生成。
描述
Before submitting
- I searched existing issues and did not find a duplicate.
- I included enough detail to reproduce or investigate the problem.
Area
apps/web
Summary
In the chat transcript, assistant text messages show a timestamp on hover. That hover timestamp is missing for the last assistant message in a turn while a command is still running (the Running command / in-progress tool state). The same message gains its hover timestamp only once the run settles.
By contrast, an assistant message that is immediately followed by a completed tool group (Ran N commands) does show its timestamp on hover, because the meta row gets relocated below the group.
Steps to reproduce
- Open any thread in
apps/weband send a prompt that makes the agent produce a text message and then run a command. - While the command is still executing (the row reads
Running command), hover over the assistant text message directly above it (e.g. "Training finished. The overall memory peak is still 14.2 GB…"). - Observe that no timestamp appears on hover.
- For contrast, hover over an earlier assistant message that is followed by a settled
Ran 2 commandsgroup — the timestamp appears on hover there.
Expected behavior
Every terminal assistant text message exposes its timestamp on hover, including the last one in a turn while a command is still running.
Actual behavior
The last assistant message before an in-progress command has no hover timestamp. It only appears after the run settles.
Impact
Cosmetic issue
Root cause (investigated)
The hover timestamp is carried by the AssistantMessageMeta row, which is gated by showAssistantMeta. That flag is forced to false while the message's run is still active, and the relocation pass that normally moves the meta below a trailing tool group is skipped for exactly those messages — so there is nothing to reveal on hover.
1. showAssistantMeta is suppressed while the run is active — apps/web/src/components/chat/MessagesTimeline.logic.ts:1986-1996
const assistantResponseStillInProgress =
timelineEntry.message.role === "assistant" &&
runIdIsActiveResponse(timelineEntry.message.runId);
const showAssistantMeta =
timelineEntry.message.role === "assistant" &&
terminalAssistantMessageIds.has(timelineEntry.message.id) &&
!assistantResponseStillInProgress; // <-- false while a command runs
When a command is running, runIdIsActiveResponse (MessagesTimeline.logic.ts:1466-1467) returns true for the message's run, so showAssistantMeta is false. The inline meta is therefore not rendered (apps/web/src/components/chat/TimelineAssistantRows.tsx:64), so there is no hover target.
2. The trailing-tool-group relocation skips in-progress messages — MessagesTimeline.logic.ts:1209-1300 (attachTrailingToolGroupsToAssistant)
This is what makes the Ran 2 commands (completed) case work: for each assistant message with showAssistantMeta === true, it finds the trailing completed tool group and re-emits the meta as a standalone assistant-meta row positioned below the group. But its gate excludes any message whose meta was already suppressed:
if (
row.kind !== "message" ||
row.message.role !== "assistant" ||
!row.showAssistantMeta || // <-- running-command message already excluded here
runId === null
) {
continue;
}
So for the in-progress case there is neither an inline meta nor a relocated assistant-meta row → no hover timestamp anywhere.
Why the two cases diverge
| Case | Run state | showAssistantMeta |
Meta row rendered? | Hover timestamp |
|---|---|---|---|---|
msg → Ran 2 commands |
settled | true |
relocated assistant-meta below group |
✅ shows |
msg → Running command |
active | false |
none (inline suppressed, relocation skipped) | ❌ missing |
Suggested fix direction
Allow the terminal assistant message to own a hover timestamp while its run is still active — e.g. relax the !assistantResponseStillInProgress suppression at MessagesTimeline.logic.ts:1993-1996 (the streaming guard in TimelineAssistantRows.tsx:184 already hides the timestamp during streaming), and/or extend attachTrailingToolGroupsToAssistant so an in-progress trailing command also produces an assistant-meta row.
Relevant files
apps/web/src/components/chat/MessagesTimeline.logic.ts—showAssistantMeta(1993-1996),attachTrailingToolGroupsToAssistant(1209-1300),runIdIsActiveResponse(1466-1467)apps/web/src/components/chat/TimelineAssistantRows.tsx—AssistantMessageMeta(144-196), timestamp render gated on!message.streaming(184-193)apps/web/src/components/chat/MessagesTimeline.tsx—group/assistanthover scope (1314-1317)
Version or commit
main @ 0712398
Environment
apps/web (web app). Observed on macOS. Provider/model: Claude (SFT training thread in screenshot).
Screenshots
Contributions welcome
This is open for anyone who wants to pick it up — the root cause and a suggested fix direction are laid out above. If you'd like to take it, leave a comment so we don't double up, and feel free to ask questions on the issue.
- 主要语言
- TypeScript
- 星标
- 24.8k
- 派生
- 6.4k
- 平均合并
- 2 小时 48 分钟
- 30 天内合并 PR
- 353
环境准备
在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 阅读贡献指南
从这里开始
- 先读完整个 Issue,再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库,在一个分支上完成修改。
- 提交 Pull Request,并在描述里引用这个 Issue 编号。
pingdotgg/t3code 的其他 Issue
-
难度 2/5 1-3 小时 新手友好度 76/100
维护者通常 1 天内回复
-
Diff line counts use Indian numeral grouping on en_IN locale (inconsistent toLocaleString calls)未关闭
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 74/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 72/100
维护者通常 1 天内回复
-
bug needs-triage
难度 2/5 1-3 小时 新手友好度 68/100
维护者通常 1 天内回复
相似的 Issue
-
area: server priority: P3 type: bug
难度 2/5 1-3 小时 新手友好度 83/100
appandflow/stim#4538 ·
维护者通常 1 天内回复
-
[BUG] Published Docker images lack the redis extra: HEADROOM_COMPRESS_SESSION_STORE stops startup可能已有人在做 @AlessandroSpallina 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 76/100
headroomlabs-ai/headroom#4513 ·
维护者通常 1 天内回复
-
bug extension extension: obsidian platform: Windows
难度 2/5 1-3 小时 新手友好度 68/100
raycast/extensions#32838 · 1 条评论 ·
维护者通常 1 天内回复
-
copy design-review mac P3
难度 2/5 1-3 小时 新手友好度 88/100
tosunlab/hisarapp-core#510 ·
-
bug priority-medium to-agent
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 1 天内回复