Skip to content

Repository navigation

fix(web): stop marking mixed tool runs as failed

MacroscopeApp / Macroscope - UI Consistency failed Aug 22, 2026 in 1m 11s

UI Consistency: 1 issue found

apps/web/src/components/chat/MessagesTimeline.logic.ts (lines 963-965) — The some → every change was applied to both work-toggle rows, but the second site drives the overflow ("+N previous log entries") toggle, whose indicator is rendered with aria-label="Hidden work includes a failure". With every, a single failed entry hidden among successful ones no longer shows the destructive x icon or the a11y label, removing the only cue that a failure is hidden inside the collapsed group and leaving the retained label copy describing behavior the code no longer implements. Suggested fix: keep some for the hidden-entries toggle (existential signal) and retain every only for the tool-group summary row (all-failed = failed group), which is the PR's intended grouping change.

An inline comment with a suggested fix has been posted.

Details

Note

Your check run agent prompt is: .macroscope/check-run-agents/ui-consistency.md
More information about how Check Run Agents work can be found in our Help Center.

Scope reviewed: apps/web/src/** files in the diff — MessagesTimeline.logic.ts, MessagesTimeline.logic.test.ts, MessagesTimeline.test.tsx. Server-side files were read only as context.

Checks performed:

  • Traced both changed hasFailure computations to their render sinks in MessagesTimeline.tsx (lines 1550-1620): the summary row (row.hasFailure → destructive x + aria-label="Tool call failed") and the overflow row (showHiddenFailure → destructive x + aria-label="Hidden work includes a failure").
  • Verified no vacuous-truth hazard from every: both call sites are guarded by non-empty arrays (visibleGroupedEntries.length > 0, hiddenEntries.length > 0).
  • Reviewed workEntryDisplayIndicatesToolFailure in apps/web/src/session-logic.ts to confirm mixed groups (e.g. reads plus one failed command) evaluate to false under every, so the overflow failure cue effectively never fires in realistic mixed groups.
  • Confirmed the added tests cover only the summary-row path (two tool-like entries, summary present); the overflow-toggle path at line 952 is not covered by the new cases.
  • No shared-primitive, Tailwind ownership, theme/variant, scroll/mask, or layout-preservation issues were introduced by this diff; class strings and markup in MessagesTimeline.tsx were unchanged.
🔍 Agent activity — 5 tool calls

💭 I'm checking whether switching from some to every for hasFailure actually changes behavior—since every on an empty array returns true, an empty group could get flagged as a failure incorrectly.

1. browse_code — apps/web/src/components/chat/MessagesTimeline.logic.ts

2. git_tools — hasFailure

💭 Both every checks operate on non-empty arrays, so there's no vacuous-truth issue there. The real question is whether switching from "any failure" to "all failed" logic is an intentional regression—given the PR is titled around improving grouped tool errors, it seems the goal is for mixed groups (some success, some failure) to display neutrally rather than as failed. But I want to check whether that failure signal becomes completely invisible when the group is collapsed. I need to look at how the collapsed state renders around lines 1540-1600 in MessagesTimeline.tsx to see if a destructive indicator still appears for a group containing one failed call, or if that signal only surfaces after expanding—which could be a discoverability or accessibility concern worth flagging against the visual preservation guidelines.

3. browse_code — apps/web/src/components/chat/MessagesTimeline.tsx

💭 I'm examining the two hasFailure call sites: the tool group summary row (line 897) fits every since it summarizes the whole group's status, but the "+N previous log entries" toggle (line 963) has an aria-label meaning "hidden work includes a failure" — switching to every there would break that semantic, since it'd only trigger when all hidden entries fail rather than just one. Checking the added tests, they only cover the summary path with two failing entries, leaving the second toggle path (hiddenEntries, onlyToolEntries) untested — a single hidden failure among many would now go unsurfaced, silently hiding real problems from the user. Also, since workEntryDisplayIndicatesToolFailure likely ignores lifecycle/read entries that never signal failure, mixing reads with one failed command makes every false almost by default, so the indicator basically only fires when literally everything fails. That's plausible for the summary row per the PR's intent, but wrong for the overflow toggle, and since the aria-label text is pre-existing and unchanged in the tsx, this patch directly turns a previously correct label into a misleading one — worth flagging as a regression introduced by this change.

4. git_tools — function workEntryDisplayIndicatesToolFailure

💭 I'll add an inline comment on lines 963-965 of MessagesTimeline.logic.ts, since that line falls within the changed diff. I'm deciding not to flag the earlier mixed-groups-neutral change since it's the intended fix supported by tests and the PR title, though the summary row could arguably hide failures too.

5. modify_pr — One finding: the overflow ("+N previous log entries") toggle's failure affordance now requires every hidden entry to have failed, which contradicts its own "Hidden work includes a failure" semantics and hides a single failure behind a collapsed group.

Agent Credits: 39 credits

View more details on MacroscopeApp