fix: filter system daemons from mic detection to prevent false notifications#3722
Conversation
…cations Remove the fallback in resolve_via_nsrunningapp_inner that returned processes based solely on bundleIdentifier when no .app bundle was found. System daemons like avconferenced (FaceTime audio daemon) would slip through this fallback and trigger false 'Meeting in progress?' notifications. Now only processes with an actual .app bundle path are resolved to apps. Co-Authored-By: yujonglee <yujonglee.dev@gmail.com>
✅ Deploy Preview for hyprnote-storybook canceled.
|
✅ Deploy Preview for hyprnote canceled.
|
🤖 Devin AI EngineerI'll be helping with this pull request! Here's what you should know: ✅ I will automatically:
Note: I can only respond to comments from users who have write access to this repository. ⚙️ Control Options:
|
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| } | ||
| for app in &apps { | ||
| assert!( | ||
| !app.name.ends_with('d') || app.name.contains('.'), |
There was a problem hiding this comment.
🟡 Test heuristic falsely flags legitimate apps like "Discord" as system daemons
The test_mic_using_apps_no_system_daemons test uses the heuristic !app.name.ends_with('d') || app.name.contains('.') to detect system daemons. This assertion fails for any legitimate app whose display name ends with 'd' and doesn't contain '.', such as "Discord", "Rewind", or "Alfred".
Detailed Explanation
The assertion at line 188:
!app.name.ends_with('d') || app.name.contains('.')is logically equivalent to: "if the name ends with 'd', it must contain '.'". System daemons like avconferenced end with 'd' and don't contain '.', but so do many legitimate apps.
For example, if Discord is using the mic, read_bundle_info at crates/bundle/src/bundle.rs:24-27 would return name: "Discord" from CFBundleDisplayName or CFBundleName. This name ends with 'd' and doesn't contain '.', so the assertion would fire:
detected app 'Discord' (com.hnc.Discord) looks like a system daemon
While this test is #[ignore] and only run manually, its stated purpose is to verify that the daemon filtering works correctly during a meeting. A false failure when a legitimate app like Discord is using the mic defeats the test's purpose and could confuse developers running the manual verification.
Impact: Manual verification test produces false positives for legitimate apps, undermining confidence in the test results.
Prompt for agents
Replace the heuristic at line 188 in crates/detect/src/list/macos.rs with a more reliable check. Instead of checking if the app name ends with 'd' and doesn't contain '.', consider checking against a known list of system daemon paths or bundle IDs. For example, you could check that the app's bundle ID doesn't match known system daemon patterns like 'com.apple.avconferenced', or verify that the resolved app path starts with '/Applications' rather than '/usr/libexec' or '/System/Library'. Alternatively, simply remove the assertion and rely on the println output for manual inspection, since the test is already marked as #[ignore] for manual verification.
Was this helpful? React with 👍 or 👎 to provide feedback.
1 participant
fix: filter system daemons from mic detection
Summary
Fixes false "Meeting in progress?" notifications caused by
avconferenced(macOS FaceTime audio daemon) being detected as a mic-using app.Root cause:
resolve_via_nsrunningapp_innerhad a fallback that returned processes based solely onbundleIdentifierwhen no.appbundle was found. System daemons likeavconferencedhave a bundle identifier but no.appbundle, so they slipped through and started the 3-minute prolonged usage timer — triggering a notification even when no meeting was active.Fix: Remove the
bundleIdentifier-only fallback. Nowresolve_via_nsrunningapp_inneronly returns apps that have a valid.appbundle path viafind_outermost_app. IfbundleURL()is absent or the path doesn't contain an.appbundle, the function returnsNone. The existingresolve_via_sysinfofallback inresolve_to_appstill serves as a second resolution attempt using the exe path, which also requires finding a.appbundle.Added test cases (2 non-ignored for
find_outermost_apppath filtering, 2 ignored for manual macOS verification).Review & Testing Checklist for Human
bundleIdentifierbut whosebundleURLdoesn't resolve to an.appbundle viafind_outermost_app. Are there real meeting apps (Electron-based, non-standard installs) that could be affected? Theresolve_via_sysinfofallback mitigates this, but worth thinking through.cargo test -p detect --features list,mic,app test_mic_using_apps_no_system_daemons -- --ignored --nocapturewhile a meeting app (Zoom, FaceTime) is using the mic. Verify real apps still appear andavconferenceddoes not.avconferenced.Notes