Problem

When a Bluetooth audio device (e.g. AirPods) is hijacked by another app or becomes silent, the zero-fill watchdog detects this and triggers an automatic reconnect after 30 seconds. However, the health endpoint still reports the device as 'ok', making it impossible for users or the UI to know there's an issue until the watchdog fires.

Root cause

The health check didn't distinguish between a device that is:

• Actively capturing audio (ok)
• Active but producing no data due to hijack (active_no_data)

The watchdog already tracks these hijack/silence events in the stream_timeouts metric, but this wasn't surfaced in the health status.

Fix

Add logic to detect stream_hijacked condition (stream_timeouts > 0) and report active_no_data status instead of ok. This allows:

1. Users/UI to see the device is degraded while recovering
2. Better diagnostics of transient Bluetooth issues
3. Clearer distinction in logs and monitoring

The watchdog will automatically trigger a reconnect; this just makes the transient state visible.

Changes

• Added stream_hijacked check in health.rs using stream_timeouts > 0
• Updated audio_status logic to emit active_no_data when hijack detected
• Enhanced health detail logs to explain the condition
• Added comprehensive unit test with both positive and negative cases

Confidence: 8/10

• Fix is straightforward: single condition check in existing health logic
• Leverages existing, proven watchdog metric (stream_timeouts)
• No side effects: new status only emitted when watchdog has already fired
• Test coverage verifies both hijacked and normal states
• No behavior changes to actual reconnection logic (that already works)

Verification (Tier T1)

Test output:

running 3 tests
test routes::health::tests::audio_status_active_no_data_when_stream_timeouts_nonzero ... ok
test routes::health::tests::health_response_is_cloneable ... ok
test routes::health::tests::health_cache_fresh_then_stale ... ok

test result: ok. 3 passed; 0 failed; 0 ignored; 0 measured; 356 filtered out; finished in 0.00s

Sources (multi-source)

• Sentry: Bluetooth device failures (SCREENPIPE-CLI) — 174+ events/24h
• GitHub issue: Audio recording silently stops mid-session when Bluetooth device (AirPods) is reused by another app, despite "ON" status #3144 (Bluetooth audio stops working) — detailed user report with reproduction steps
• Git history: Commit 357e4df (zero-fill watchdog) — verifies the infrastructure exists, just needs health visibility

Fixes #3144

auto-generated by issue-solver pipe