Skip to content

Require two consecutive readings before rebuilding a starved tap - #40

Merged
andyhtran merged 1 commit into
mainfrom
fix-watchdog
Aug 8, 2026
Merged

Require two consecutive readings before rebuilding a starved tap#40
andyhtran merged 1 commit into
mainfrom
fix-watchdog

Conversation

@andyhtran

Copy link
Copy Markdown
Owner

Summary

  • The watchdog's tap-starvation check now uses a two-stage verdict (healthy / suspect / starved) instead of a single-read boolean
  • A first over-threshold latency sample only raises suspicion; only a second consecutive bad reading triggers a rebuild
  • Prevents false-positive tap rebuilds caused by stale latency samples observed on macOS 26 after long idle stretches

Test plan

  • Unit tests updated and passing (swift test --filter TapStarvationPolicyTests — 8 tests)
  • just dev — confirm app launches and shortcuts work
  • Leave idle past silence threshold, check Console.app for "re-checking next tick" (suspect) rather than immediate rebuild

🤖 Generated with Claude Code

…tarved tap

A single latency sample can be stale after a long quiet stretch (observed
on macOS 26), so the watchdog now treats the first bad reading as suspect
and only convicts on a second consecutive one. Reading the tap list resets
the window server's accumulator, which is what makes the confirmation
reliable: a stale sample cannot survive its own read.
@andyhtran
andyhtran merged commit 10387d8 into main Aug 8, 2026
1 check passed
@andyhtran
andyhtran deleted the fix-watchdog branch August 8, 2026 16:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant