[Bug]: Sidebar "Failed" badge does not clear when the session is opened (unlike "Done")

Read apps/web/src/components/sidebar/SidebarThreadRow.tsx around lines 684–754 and the hasUnseenCompletion and hasUnseenFailure helpers in apps/web/src/components/Sidebar.logic.ts around lines 689–708. Trace how opening a thread updates lastVisitedAt, then check the related sidebar tests before making the failure badge use the same unseen status behavior as Done. Done means opening a failed session clears its badge, including when completedAt is null.

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

1. Have a session run to completion successfully → its sidebar card shows a green Done badge.
2. Click/open that session → the Done badge clears.
3. Have another session end in failure → its sidebar card shows a red Failed badge (e.g. "Audit private file for public exposure" → (!) Failed).
4. Click/open that session.
5. 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 badge
• apps/web/src/components/Sidebar.logic.ts:689-708 (hasUnseenCompletion / unused hasUnseenFailure), 868-895 (resolveSidebarThreadStatus)
• apps/web/src/components/chat/ThreadVisitWatermark.tsx, apps/web/src/uiStateStore.ts:244, packages/client-runtime/src/state/threadVisits.ts — what advances lastVisitedAt on open
• packages/client-runtime/src/state/threadSettled.ts:100-108, packages/client-runtime/src/state/models.ts:260-275 — failed runs can have completedAt === 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.