[Bug]: Sidebar "Failed" badge does not clear when the session is opened (unlike "Done")
Los mantenedores suelen responder en 1 día
@BilalIrfanContact ya está trabajando en esto.
Desde el 26/10/2026.
- #25663 de @BilalIrfanContact — abierto
Evaluación
- Dificultad
- 2/5
- Tiempo estimado
- 1-3 horas
- Aptitud para principiantes
- 86/100
- Tipo de issue
- Error
- Claridad
- Bien especificado
- Estado de actividad
- Activo
- Stack tecnológico
- react, typescript
- Área
- frontend
Línea de trabajo
Lee apps/web/src/components/sidebar/SidebarThreadRow.tsx alrededor de las líneas 684–754 y los helpers hasUnseenCompletion y hasUnseenFailure en apps/web/src/components/Sidebar.logic.ts alrededor de las líneas 689–708. Sigue cómo abrir un hilo actualiza lastVisitedAt y, después, revisa las pruebas relacionadas de la barra lateral antes de hacer que la insignia de error use el mismo comportamiento de estado no visto que Done. Done significa que abrir una sesión fallida elimina su insignia, incluso cuando completedAt es null.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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 sidebar thread list, a session card shows a status badge. A "Done" badge clears as soon as you open that session, but a "Failed" badge does not — it stays on the card even after the session has been opened/selected in the sidebar.
The two badges should behave the same way: opening the session should acknowledge (clear) its terminal status badge, whether it finished successfully or failed.
Steps to reproduce
- Have a session run to completion successfully → its sidebar card shows a green Done badge.
- Click/open that session → the Done badge clears.
- Have another session end in failure → its sidebar card shows a red Failed badge (e.g. "Audit private file for public exposure" →
(!) Failed). - Click/open that session.
- Observe: the Failed badge is still on the card.
Expected behavior
Opening a failed session clears (acknowledges) its Failed badge, mirroring how opening a completed session clears the Done badge.
Actual behavior
The Failed badge persists on the sidebar card after the session is opened. Only Done clears on open.
Impact
Minor bug or occasional failure
Root cause (investigated)
The two badges are gated by two independent mechanisms. "Done" is gated by a visited-watermark comparison (so opening clears it); "Failed" is gated by the raw runtime status (which opening never touches).
The card and its two inputs — apps/web/src/components/sidebar/SidebarThreadRow.tsx:684-685
const isUnread = hasUnseenCompletion({ ...thread, lastVisitedAt });
const status = resolveSidebarThreadStatus(thread);
The badge ternary — SidebarThreadRow.tsx:736-754. failed is tested before isUnread, and the two come from different sources:
: status === "failed"
? { label: "Failed", icon: "failed", className: "text-error-foreground" }
: isWoke
? { label: "Woke", ... }
: isUnread
? { label: "Done", icon: "done", className: "text-success-foreground" }
: null;
- Done ⇐
isUnread⇐hasUnseenCompletion(...)— a watermark comparison. - Failed ⇐
status === "failed"⇐resolveSidebarThreadStatus(...)— raw runtime status, no watermark.
Why Done clears on open — hasUnseenCompletion compares against lastVisitedAt (apps/web/src/components/Sidebar.logic.ts:689-698):
export function hasUnseenCompletion(thread: ThreadStatusInput): boolean {
if (!thread.latestRun?.completedAt) return false;
const completedAt = Date.parse(thread.latestRun.completedAt);
if (Number.isNaN(completedAt)) return false;
if (!thread.lastVisitedAt) return false;
const lastVisitedAt = Date.parse(thread.lastVisitedAt);
if (Number.isNaN(lastVisitedAt)) return true;
return completedAt > lastVisitedAt; // false once visited after completion
}
Why Failed does NOT clear on open — resolveSidebarThreadStatus returns "failed" purely from live runtime status, with no lastVisitedAt/seen input (Sidebar.logic.ts:868-895):
if (thread.runtime?.status === "failed") {
return thread.runtime.lastErrorClass === "usage_limit" ? "limited" : "failed";
}
Opening a thread advances lastVisitedAt (local via apps/web/src/components/chat/ThreadVisitWatermark.tsx → markThreadVisited in apps/web/src/uiStateStore.ts:244; server via packages/client-runtime/src/state/threadVisits.ts). That flips hasUnseenCompletion to false (Done clears) but leaves thread.runtime.status === "failed" untouched (Failed stays).
Note: an unused hasUnseenFailure already exists
Sidebar.logic.ts:700-708 already defines a hasUnseenFailure(...) helper, but the active sidebar card (SidebarThreadRow.tsx) does not use it — it uses the raw resolveSidebarThreadStatus status instead. hasUnseenFailure is also asymmetric with hasUnseenCompletion:
function hasUnseenFailure(thread: ThreadStatusInput): boolean {
if (thread.latestRun?.status !== "failed") return false;
if (!thread.lastVisitedAt) return true;
const completedAt = Date.parse(thread.latestRun.completedAt ?? "");
const lastVisitedAt = Date.parse(thread.lastVisitedAt);
if (Number.isNaN(completedAt) || Number.isNaN(lastVisitedAt)) return true; // sticky forever when completedAt is null
return completedAt > lastVisitedAt;
}
A failed run can legitimately have completedAt === null (see packages/client-runtime/src/state/threadSettled.ts:100-108 and packages/client-runtime/src/state/models.ts:260-275, which fall back to runtime.updatedAt). In that case hasUnseenFailure returns true permanently, so even wiring it in as-is would keep the badge sticky for those runs.
Divergence
| Badge | Source | Watermark-gated? | Clears on open? |
|---|---|---|---|
| Done | hasUnseenCompletion |
yes (vs lastVisitedAt) |
✅ |
| Failed | resolveSidebarThreadStatus (runtime.status === "failed") |
no | ❌ |
Suggested fix direction
Gate the Failed badge the same way as Done in SidebarThreadRow.tsx — surface "failed" only when there is an unseen failure (use/wire in hasUnseenFailure(..., lastVisitedAt)), positioned consistently relative to the isUnread check. While doing so, make hasUnseenFailure symmetric with hasUnseenCompletion: fall back to runtime.updatedAt when latestRun.completedAt is null instead of returning true, so failures with no completedAt can still be acknowledged on open.
Relevant files
apps/web/src/components/sidebar/SidebarThreadRow.tsx:684-685, 699-754— active card badgeapps/web/src/components/Sidebar.logic.ts:689-708(hasUnseenCompletion/ unusedhasUnseenFailure),868-895(resolveSidebarThreadStatus)apps/web/src/components/chat/ThreadVisitWatermark.tsx,apps/web/src/uiStateStore.ts:244,packages/client-runtime/src/state/threadVisits.ts— what advanceslastVisitedAton openpackages/client-runtime/src/state/threadSettled.ts:100-108,packages/client-runtime/src/state/models.ts:260-275— failed runs can havecompletedAt === null
Version or commit
main @ 0712398
Environment
apps/web (web app). Observed on macOS.
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.
- Lenguaje dominante
- TypeScript
- Estrellas
- 24.8k
- Forks
- 6.4k
- Merge medio
- 4 h 29 min
- PR fusionados (30 d)
- 305
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de pingdotgg/t3code
-
bug needs-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
[Bug]: Assistant message hover timestamp missing while a command is still runningPosiblemente ocupada Un pull request vinculado a esta issue está abierto o ya se fusionó. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 87/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
bug needs-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 73/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Los mantenedores suelen responder en 1 día
Todos los issues de pingdotgg/t3code
Issues similares
-
支持对已取消(cancelled)任务生成报告Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 77/100
Clouditera/VulnHunter#57 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 1 día
-
bug bug:behavior clawsweeper:bulk-filed clawsweeper:fix-shape-clear clawsweeper:no-new-fix-pr clawsweeper:source-repro impact:auth-provider issue-rating: 🦞 diamond lobster P2
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
openclaw/openclaw#185297 · 1 comentario · 1 reacción ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
-
bug needs-triage
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
apex-dev-tools/apex-log-parser#199 ·
Los mantenedores suelen responder en 1 día