The mic was published but silent - finding an honest health signal
The product has a device health monitor: it decides whether the mic and camera work and warns the user when something drops. Three tasks in a row came not from the backlog but from real complaints.
A mic that “works” and says nothing
A user switched microphones mid-call, hit a reconnect and ended up silent. Nobody could hear them, while the interface claimed everything was fine.
The monitor treated republishing as success by the mere fact of publication: the track is published, therefore sound flows. In reality you can publish a dead track just as well. The first candidate for an honest signal was audio level, but it doesn’t work: while a person is quiet the level is zero, and a healthy mic is indistinguishable from a broken one.
The working signal lives in connection stats: bytes sent keep growing, so audio is leaving the machine. Silence doesn’t zero them out, because the codec keeps sending packets. The criterion is simple and lies neither in silence nor on device change.
Separately it turned out that a device change is easy to miss entirely. On automatic switching the library swaps the track inside the existing publication and emits no republish event. Any monitor listening only for those will never see it.
A camera that locked the button
Second case: a user unplugged the camera mid-call, it went into a “lost” state, and the toggle stayed locked until the call ended. Even plugging the camera back in changed nothing.
Indication and blocking were glued together here. I split them: the button locks only when the device is genuinely held by another application, and on a loss it stays clickable with a warning. Recovery happens by re-evaluating a fresh track, not by a flag set at the moment of failure.
An app that forgot the choice every time
The third complaint came from people running streaming software: on every join the app took the system default mic instead of the one they had picked last time. The cause was a single missing piece - the settings store had no persistence, so the chosen devices reset on each load.
I added persistence with the manual choice taking priority over the system default. The fallback is quiet: if the saved device is gone from the system, the app drops back to the system one instead of showing an error.
What the three had in common
All three lived in the code for months and escaped tests, because each is about a gap between “the state was set” and “the state matches reality”. You only see that on real hardware: unplug the camera, close the laptop, plug in a virtual microphone.