Double error toast spam on statusCheck failure (TailscaleWidget.qml)

vybe commented

2026-05-19 04:04:51 +00:00

Collaborator

Problem

statusCheck (the tailscale status --json Process) has split error handling between onStreamFinished and onExited. When the command fails or produces non-JSON output, both handlers fire and each shows its own toast:

onStreamFinished catch block → "Failed to parse Tailscale status"
onExited (code !== 0) → "Failed to read Tailscale status"

Because the 5-second status timer continues running, this produces repeated duplicate error toasts on every poll. The same duplication occurs for missing binary (exit 127) and daemon-down cases.

Impact

Users see spammy, confusing double toasts on any transient or persistent Tailscale connectivity problem. Error state is not handled in a single authoritative path, making the failure UX noisy and unhelpful.

## Problem `statusCheck` (the `tailscale status --json` Process) has split error handling between `onStreamFinished` and `onExited`. When the command fails or produces non-JSON output, both handlers fire and each shows its own toast: - `onStreamFinished` catch block → "Failed to parse Tailscale status" - `onExited` (code !== 0) → "Failed to read Tailscale status" Because the 5-second status timer continues running, this produces repeated duplicate error toasts on every poll. The same duplication occurs for missing binary (exit 127) and daemon-down cases. ## Impact Users see spammy, confusing double toasts on any transient or persistent Tailscale connectivity problem. Error state is not handled in a single authoritative path, making the failure UX noisy and unhelpful.

vybe referenced this issue

2026-05-19 04:30:56 +00:00

Lax / fragmented error handling throughout the widget (catch-all masking, missing exit checks, no stderr) #29

jtmorris referenced this issue

2026-05-19 04:54:23 +00:00

Aggressive unconditional 5-second polling even when popout is closed (battery/CPU waste) #33

jtmorris commented

2026-05-19 04:55:05 +00:00

Owner

See #33's discussion on the 5-second timer disaster design decision.

vybe referenced this issue

2026-05-19 05:17:22 +00:00

Remove redundant binaryAvailable guard from TailscaleWidget.qml #11

vybe referenced this issue

2026-05-19 05:20:51 +00:00

No stderr capture on toggleProcess / exitNodeProcess (lost diagnostic output) #25

vybe referenced this issue

2026-05-19 05:21:18 +00:00

Redundant duplicate keys in errorMessage() (up/connect, down/disconnect) #22

vybe referenced this issue

2026-05-19 05:22:07 +00:00

Missing edge-case tests for parsePeers and findActiveExitNode #21

vybe referenced this issue

2026-05-19 05:47:19 +00:00

Lax / fragmented error handling throughout the widget (catch-all masking, missing exit checks, no stderr) #29

vybe referenced this issue

2026-05-19 06:49:38 +00:00

Lax / fragmented error handling throughout the widget (catch-all masking, missing exit checks, no stderr) #29

vybe referenced this issue from a commit

2026-05-21 07:04:13 +00:00

chore: confirm single authoritative error path for statusCheck

vybe referenced this issue from a commit

2026-05-21 07:04:13 +00:00

Merge feature_fix_double_toast_spam into vibes

vybe commented

2026-05-21 07:04:13 +00:00

Author

Collaborator

Verified and resolved: parseStatusResult (lib.js:59) safely handles bad JSON without throwing. onStreamFinished only updates state. All error toasts now flow through single onExited handler (TailscaleWidget.qml:103). No double-toast possible. Merged to vibes. Written by AI agent working for @jtmorris. Model: Grok 4.3.