[Bug]: Assistant message hover timestamp missing while a command is still running
I maintainer di solito rispondono entro 1 giorno
Valutazione
- Difficoltà
- 2/5
- Tempo stimato
- 1-3 ore
- Idoneità per principianti
- 87/100
- Tipo di issue
- Bug
- Chiarezza
- Specificata chiaramente
- Stato di attività
- Attiva
- Stack tecnologico
- react, typescript
- Ambito
- frontend
Direzione di ricerca
Inizia con showAssistantMeta e attachTrailingToolGroupsToAssistant in apps/web/src/components/chat/MessagesTimeline.logic.ts, poi controlla come AssistantMessageMeta visualizza i timestamp in apps/web/src/components/chat/TimelineAssistantRows.tsx. Riproduci il problema con un comando in corso e confrontalo con un gruppo di strumenti completato. Il lavoro è completato quando il messaggio finale dell’assistente mostra il timestamp al passaggio del puntatore mentre il comando è in esecuzione, senza mostrarlo durante lo streaming.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- TypeScript
- Stelle
- 24.8k
- Fork
- 6.4k
- Merge medio
- 4h 29m
- PR unite (30g)
- 305
Preparare l'ambiente
Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di pingdotgg/t3code
-
bug needs-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
[Bug]: Sidebar "Failed" badge does not clear when the session is opened (unlike "Done")Forse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 86/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
bug needs-triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 73/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di pingdotgg/t3code
Issue simili
-
enhancement
Difficoltà 2/5 1-3 ore Idoneità per principianti 73/100
ajv-validator/ajv#2689 ·
-
[Bug]: IME confirmation Enter can submit the SSH port-forward dialogForse già presa @seijikohara l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
home-assistant/frontend#55323 ·
I maintainer di solito rispondono entro 1 giorno
-
community first-timers-only good first issue hacktoberfest help wanted low hanging fruit up-for-grabs
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 72/100
lingdojo/kana-dojo#33188 · 1 commento · 5 reazioni ·
I maintainer di solito rispondono entro 1 giorno
-
self-driving
Difficoltà 1/5 1-3 ore Idoneità per principianti 86/100
I maintainer di solito rispondono entro 1 giorno