Timer continues polling after tailscale binary disappears or fails

vybe commented

2026-05-21 07:43:34 +00:00

Collaborator

Problem: The 5-second status timer in TailscaleWidget.qml keeps firing even when the tailscale binary is absent or broken. Historical behavior was toast spam; current guards only partially mitigate it. No explicit test or contract exists for the "binary unavailable" lifecycle.

Written by AI agent working for @jtmorris. Model: Grok 4.3.

Problem: The 5-second status timer in TailscaleWidget.qml keeps firing even when the tailscale binary is absent or broken. Historical behavior was toast spam; current guards only partially mitigate it. No explicit test or contract exists for the "binary unavailable" lifecycle. Written by AI agent working for @jtmorris. Model: Grok 4.3.

vybe commented

2026-05-21 19:02:41 +00:00

Author

Collaborator

Fixed in PR #53. Added refreshTimer ID and guarded the trigger with if (!statusCheck.running) so the timer won't spawn a new tailscale status process while one is already running. Also added binaryAvailable property: if statusCheck exits with code 127 (binary not found), the flag flips to false and toggleTailscale()/setExitNode() short-circuit with a toast instead of invoking the missing binary.

Remaining: The timer itself never stops polling — it just skips redundant calls. A stricter fix would stop the timer entirely on code 127, but that risks never recovering if tailscale is installed later. Current approach is a reasonable balance.

Fixed in PR #53. Added `refreshTimer` ID and guarded the trigger with `if (!statusCheck.running)` so the timer won't spawn a new `tailscale status` process while one is already running. Also added `binaryAvailable` property: if `statusCheck` exits with code 127 (binary not found), the flag flips to `false` and `toggleTailscale()`/`setExitNode()` short-circuit with a toast instead of invoking the missing binary. Remaining: The timer itself never stops polling — it just skips redundant calls. A stricter fix would stop the timer entirely on code 127, but that risks never recovering if tailscale is installed later. Current approach is a reasonable balance.

jtmorris commented

2026-05-21 19:28:33 +00:00

Owner

Don't like this. See issue #11. See your AGENT.md file's discussion of storing state. We explicitly removed this approach to using a binaryAvailable flag, and were opting to instead enter an error state in which all tailscale binary calls are disabled/hidden. binaryAvailable opens up edge cases and stale state issues we shouldn't have to handle. Further, what gain is it to check if the binary exists by probing for exit code 127, when you can just check at invocation if you're getting an error exit code? You will need to do this check anyway to handle the edge case where binaryAvailable is out-of-sync with reality (e.g., the user uninstalls Tailscale).

Don't like this. See issue #11. See your AGENT.md file's discussion of storing state. We explicitly removed this approach to using a `binaryAvailable` flag, and were opting to instead enter an error state in which all `tailscale` binary calls are disabled/hidden. `binaryAvailable` opens up edge cases and stale state issues we shouldn't have to handle. Further, what gain is it to check if the binary exists by probing for exit code 127, when you can just check at invocation if you're getting an error exit code? You will need to do this check anyway to handle the edge case where `binaryAvailable` is out-of-sync with reality (e.g., the user uninstalls Tailscale).