feat(#33 follow-up): Hook addNotification into streaming errors, MCP failures, export, and updater

[andrewchumchal]

The notification system (#33) is wired up (AppNotification type, addNotification/markRead/markAllRead/clearNotifications in uiStore, bell popover in StatusBar) but nothing calls addNotification yet.

Places to hook in

Streaming errors

• When an AI request fails, currently shows inline in the chat only
• Should also fire addNotification({ title: 'Request failed', message: error.message, variant: 'error' })
• Location: useChat hook (error handler)

MCP tool errors

• When a tool call fails or times out
• Should fire addNotification({ title: 'Tool call failed', message: \${toolName}: ${error}`, variant: 'warning' })`
• Location: MCP client error paths + useOnToolCall

Export / save

• After a successful conversation export
• addNotification({ title: 'Exported', message: 'Conversation saved to file', variant: 'success' })
• Location: lib/export.ts or wherever export is triggered

Auto-updater

• When the Cloudflare worker returns a new version
• addNotification({ title: 'Update available', message: \v${latestVersion} is ready`, variant: 'info' })`
• Location: ipc.ts updater handler → renderer via IPC → addNotification

Notes

• Keep payloads serializable (no React nodes) so future extension callers (spec: Extension Platform SDK — installable extensions with activity bar, commands, settings, and hook contributions #38) can fire them over IPC
• source field should be set to 'app' for all built-in callers

[Ilya0527]

One thing worth distinguishing for MCP: tool failures arrive at two different layers and warrant different notification behavior. A JSON-RPC error response (transport down, server crashed, method not found) is a real failure. But the MCP spec defines tool-level errors as a successful response with isError: true in the content array — these are errors the LLM is meant to see and recover from (file not found, empty query result, validation failed), and surfacing them as warning toasts will produce a notification per retry attempt during normal agent loops. The cleaner split is to call addNotification only on JSON-RPC errors and client-side timeouts, never on isError: true content blocks — those are model-visible by design and the agent loop handles them.

Two adjacent traps for the other hooks. The useChat error handler will fire for AbortError whenever the user clicks stop or navigates away mid-stream; without an error.name === 'AbortError' filter, every cancel becomes a "Request failed" toast. And if the MCP transport drops mid-conversation, every queued tool invocation rejects with the same connection error — without dedup by (source, title) within a short window, one disconnect becomes N notifications.

Does the current useOnToolCall distinguish isError: true content from JSON-RPC failures, or do they share a single error path today?

---

Generated via ALEF Pattern Catalog v2.4.11-alpha · autonomous research agent · operator-supervised · transparency · support

[Ilya0527]

The MCP tool-error hook needs to handle both failure modes, not just the catch path. Per the MCP spec, CallToolResult includes an optional isError: boolean — when a tool execution fails on the server side, the JSON-RPC response still resolves successfully and the SDK's client.callTool() returns normally with isError: true plus the error text in content. Only transport-level failures (no response, parse error, timeout, schema validation) reject the promise. If you wire addNotification solely into useOnToolCall's catch branch or the MCP client's error path, every server-reported tool failure — bad args, file-not-found, the tool implementation threw — silently bypasses the bell while the chat shows the inline error.

Hooking both paths also affects the variant choice: transport timeouts probably want 'error', in-band isError: true reads closer to 'warning', and the dedup key should include toolName + errorCode so a misconfigured tool doesn't spam the popover on retry. Worth checking: does the current inline tool-error rendering in chat read from the rejected-promise branch, the resolved result.isError field, or both? If it's only one of those, that's the gap to close before adding the addNotification call — otherwise half the failures will keep slipping past.

---

Generated via ALEF Pattern Catalog v2.4.11-alpha · autonomous research agent · operator-supervised · transparency · support