fix(desktop): make error cards dismissable + softer tone for recoverable ones#1487
Merged
Conversation
User report: storm-repair / repeat-loop warnings pile up as red error
cards in the desktop transcript with no way to close them. A handful
of self-repaired loops in a long session leaves a wall of "错误" cards
permanently sitting in the chat, even though the loop already worked
around the underlying problem.
The kernel-side already classifies these correctly — KernelErrorEvent
carries `recoverable: true` for storm-repair / repeat-loop notices and
`false` for hard failures. The desktop just wasn't using either signal:
- Every error event got the same red tone with no dismiss UI.
This commit:
- Adds an id to each error chat message so dismiss can target one
without taking out unrelated messages.
- New `dismiss_error` action + reducer case removes by id.
- Each error card now renders a close (×) button. Click dispatches
`dismiss_error` for that id.
- When the kernel event marks the error `recoverable: true`, the
card renders with warn tone (warningLabel + tone-warn border/text)
instead of error tone — softer signal for things the loop already
handled.
- Protocol `$error` events (RPC-layer hard failures) keep the red
error tone.
i18n: added `app.warningLabel` and `app.dismissError` for en + zh-CN.
3539 tests pass (+4: dismiss_error by id; no-op for missing id;
recoverable=true from kernel error; recoverable=false from \$error).
esengine
pushed a commit
that referenced
this pull request
May 21, 2026
- App.tsx $session_empty branch was missing `id` on the error card so TS rejected the literal against ChatMessage's required-id variant. - App.test.ts stub state still used the pre-#1487 UsageStats shape (`tokens.{input,output,...}`); update to the current flat shape so the test compiles. Caught by the desktop-v* release workflow — root verify doesn't run desktop tsc, so these regressed silently after #1487.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bug
Desktop transcript fills up with red "错误" / "Error" cards that have no close button — every storm-repair / repeat-loop guard notice the loop emits gets rendered as a permanent red error card. A long session ends up with a wall of them at the bottom of the chat, even though the loop already worked around each issue.
User report (screenshot): three stacked cards along the lines of
…all rendered identically with red tone and zero affordance to dismiss.
Root cause
`KernelErrorEvent` already carries `recoverable: boolean` — `true` for storm-repair / repeat-loop warnings, `false` for hard failures. The desktop reducer ignored the flag and pushed every event as the same red card with no close button. Storm-repair text reads as a confusing string of "ERRORS" when the loop already handled them.
Fix
Tests
4 new reducer tests in `tests/desktop-btw-status.test.ts`:
3539 tests pass locally.
Test plan