Notification Doesn't Appear

[zerodable]

Bug Description
On Windows 11, toast notifications are completely failing to trigger when receiving new messages. The app receives the message internally, but no system-level notification is pushed to the OS.

Environment Details

• OS: Windows 11 (Specify your build, e.g., 23H2)
• App Version: (0.3.1)
• Installation Method: Downloaded .msi

Steps to Reproduce

1. Install whatRust on Windows 11.
2. Pin the app to the Start Menu and launch it from the Start Menu to ensure AUMID constraints are met.
3. Ensure Windows "Do not disturb" is off and notifications are enabled for the app in Windows Settings.
4. Ensure internal WhatsApp Web desktop alerts are checked in the app's UI.
5. Receive a new message while the app is minimized or unfocused.

Expected Behavior
A Windows toast notification should appear.

Actual Behavior
No toast notification appears.

Troubleshooting Already Performed
I have already ruled out local environment issues:

• Clean WebView2 Install: Reinstalled Microsoft Edge WebView2, but the issue persists.
• Event Viewer Check: Checked Applications and Services Logs > Microsoft > Windows > PushNotification-Platform > Operational. There are no rejection or drop logs recorded when a message arrives, indicating the payload is never reaching the Windows Action Center.
• Forced AUMID Registration: Used a PowerShell script to manually inject com.whatrust.app (and variations) into HKCU:\SOFTWARE\Classes\AppUserModelId, but notifications still fail to trigger.

It appears the tauri-plugin-notification payload or the AUMID configuration in tauri.conf.json may not be configured correctly for Windows 11 requirements.

[karem505]

Thanks for the unusually thorough report — the Event Viewer / PushNotification-Platform check and the manual AUMID injection are exactly the right things to look at, and they pointed straight at the cause.

Root cause

It's an AppUserModelID (AUMID) registration problem, and your "no drop logs, payload never reaches Action Center" observation is the key clue.

On an installed build, tauri-plugin-notification stamps every toast with System.AppUserModel.ID = com.karem.whatrust (the app's bundle identifier). Windows will only render a toast whose AUMID is registered on the system. When it isn't effective at the moment the toast fires — e.g. the toast is raised from a process the shell didn't associate with the AUMID-bearing Start-Menu shortcut, the Desktop shortcut (which has no AUMID) was used, a per-user/per-machine path mismatch, or the shortcut lost its property — the WinRT call fails silently. whatRust then discarded that error in three places, so you got no toast and nothing in the logs. (In dev/cargo run the plugin falls back to the always-registered PowerShell AUMID, which is why this only bites installed builds.)

One detail from your troubleshooting: the registry AUMID you injected was com.whatrust.app, but the identifier the app actually uses is com.karem.whatrust — so those entries wouldn't have matched. You can confirm the diagnosis on your current (broken) install with:

reg query "HKCU\Software\Classes\AppUserModelId\com.karem.whatrust"

On the current build that key is absent.

The fix (PR #4)

On startup (Windows-only, per-user, no admin, idempotent) the app now:

1. registers HKCU\Software\Classes\AppUserModelId\com.karem.whatrust with a DisplayName, and
2. calls SetCurrentProcessExplicitAppUserModelID("com.karem.whatrust").

That makes toast delivery self-sufficient regardless of how the app was installed or launched, and a shortcut that lost its AUMID self-heals on the next launch. I also stopped swallowing the notification error and now log it, so if anything still fails it's diagnosable.

Could you help confirm?

I develop on Linux, so I verified the fix compiles for the Windows target + passes the logic/CI checks, but I can't watch a toast actually pop here. Once the next build is out, please:

1. Install it, reboot or re-launch from the Start Menu, and send yourself a message while whatRust is minimized — you should now get a toast.
2. If you want to verify immediately after installing, reg query "HKCU\Software\Classes\AppUserModelId\com.karem.whatrust" should now return the key with DisplayName = whatRust.
3. If it still doesn't appear: run the exe from a console (& "$env:LOCALAPPDATA\<install path>\whatRust.exe") and send a message — you'll now see a [whatrust] failed to show notification: ... line with the HRESULT; please paste it here. Also worth a quick check that Focus Assist / Do Not Disturb is off and whatRust is enabled under Settings → System → Notifications.

I'll leave this open until you can confirm on a real Windows 11 install. Thanks again for the great report!

[karem505]

The fix is now released in v0.3.2 — installers are built and published:

• NSIS (recommended): whatRust_0.3.2_x64-setup.exe
• MSI: whatRust_0.3.2_x64_en-US.msi

Could you install it and confirm a toast appears? After installing, you can sanity-check the registration with:

reg query "HKCU\Software\Classes\AppUserModelId\com.karem.whatrust"

It should now show DisplayName = whatRust. If a toast still doesn't appear, launch the exe from a console and send a message — you'll get a [whatrust] failed to show notification: ... line with an HRESULT; paste it here and I'll dig further. I'll keep this open until you've had a chance to verify. Thanks!

[zerodable]

Thank you so much for your time and effort in looking into this. I really appreciate your responsiveness and all the hard work you put into this!

However, I tested v0.3.2 and the issue persists.

Environment

• OS: Windows 11
• App Version: whatRust v0.3.2 (.exe NSIS)
• App ID Linkage: Installed app is recognized by Windows (Get-StartApps shows whatRust with AppID com.karem.whatrust).
• Registry: Registry key HKCU\Software\Classes\AppUserModelId\com.karem.whatrust exists.
• Execution Context: App launched from the Start Menu.

Observed Behavior

• Notification sound plays when a new message arrives.
• No Windows toast notification is shown.
• whatRust still does not appear under Settings → System → Notifications.

Additional Diagnostics

• Console Output: Running the release executable from PowerShell produces no console output, even when redirecting stdout/stderr to a file.
• Profile Test: I have tried to install the app on a completely different Windows account on the same machine to make sure my main user system profile is not corrupted. The exact same issue occurs.
• Baseline Comparison: WhatsApp Desktop notifications work normally on the same machine.

It seems the AUMID registration issue may have been resolved in v0.3.2, but toast delivery itself is still failing.

Could you either provide a quick debug/console build here, or add file-based logging (like writing to %LOCALAPPDATA%\whatRust\logs) so I can pull that exact error code for you? I am happy to keep testing!

[karem505]

Thanks again — that's a fantastic diagnostic write-up, and a couple of details in it change the picture in a useful way.

First, the good news: the AUMID registration from v0.3.2 worked (you confirmed Get-StartApps + the HKCU\...\AppUserModelId\com.karem.whatrust key), so that part is done. But the toast still doesn't render, and the reason we had no error to look at is two-fold:

1. No console. whatRust is a GUI-subsystem app, so it has no attached stdout/stderr — that's why redirecting in PowerShell captured nothing (the v0.3.2 eprintln! had nowhere to go). You were right to ask for file logging.
2. The notification plugin hides the result. tauri-plugin-notification's show() fires the actual Windows toast on a background task and throws the result away, so even internally the failure never surfaces.

Also worth flagging: the sound you hear is almost certainly WhatsApp Web's own in-page sound (the webpage plays it via JS), not the Windows toast sound — so it doesn't tell us the OS toast was ever attempted. We need to separate "did our app try to notify?" from "can Windows render a toast for this AUMID at all?".

v0.3.3 — diagnostic build (not a fix yet)

I've shipped v0.3.3 which adds file-based logging (no message content is logged — just control flow + error codes):

• NSIS: whatRust_0.3.3_x64-setup.exe

To pinpoint this, could you do two quick things?

1) Install v0.3.3, receive a message, then paste the log:

Get-Content "$env:LOCALAPPDATA\whatRust\logs\whatrust.log"

What I'm looking for there:

• if you see commands::notify invoked → our app is trying to notify, and the failure is in the Windows toast layer;
• if you don't see it when a message arrives → WhatsApp Web delivered the notification through a path our shim doesn't intercept (e.g. the service worker), and the fix is on our side in the page bridge;
• plus the real aumid: registration results.

2) Run this standalone toast test (it asks Windows to show a toast for our exact AUMID, completely independent of whatRust — close the app first):

$aumid = "com.karem.whatrust"
$null = [Windows.UI.Notifications.ToastNotificationManager, Windows.UI.Notifications, ContentType=WindowsRuntime]
$null = [Windows.UI.Notifications.ToastNotification, Windows.UI.Notifications, ContentType=WindowsRuntime]
$null = [Windows.Data.Xml.Dom.XmlDocument, Windows.Data.Xml.Dom, ContentType=WindowsRuntime]

$xml = New-Object Windows.Data.Xml.Dom.XmlDocument
$xml.LoadXml(@"
<toast><visual><binding template="ToastGeneric">
<text>whatRust test</text>
<text>If you can see this banner, the AUMID can render toasts.</text>
</binding></visual></toast>
"@)

try {
    $notifier = [Windows.UI.Notifications.ToastNotificationManager]::CreateToastNotifier($aumid)
    $toast = [Windows.UI.Notifications.ToastNotification]::new($xml)
    $notifier.Show($toast)
    "Submitted with no error — did a banner appear? (yes/no)"
} catch {
    "ERROR: $($_.Exception.Message)"
}

• Banner appears → the AUMID is fine; the problem is purely in how whatRust calls the toast API, and I'll fix that directly.
• No banner / error thrown → Windows itself won't render toasts for this AUMID yet (a desktop app usually needs a Start-Menu shortcut carrying the AUMID property, not just the registry key) — and I'll add that registration.

Between the log and this test we'll know exactly which layer is failing, and I can ship a real fix rather than guessing. Really appreciate your patience and the careful testing!

[zerodable]

Thanks for the instant reply, I already try the v0.3.3 and completed both tests on v0.3.3 you asked for. Here are the results:

1) Log output after receiving a WhatsApp message

After installing the v0.3.3 and tried to message myself, heres the output of the log afterwards:

PS C:\WINDOWS\system32> Get-Content "$env:LOCALAPPDATA\whatRust\logs\whatrust.log"

[1781494073] === session start ===
[1781494073] aumid: HKCU\Software\Classes\AppUserModelId\com.karem.whatrust registered
[1781494073] aumid: SetCurrentProcessExplicitAppUserModelID(com.karem.whatrust) ok

I did not see any additional entries such as commands::notify invoked after receiving trying to send several messages to myself (personal chat, group)

2) Standalone Windows toast test

I closed whatRust and ran the PowerShell script exactly as provided.

Result:

Submitted with no error — did a banner appear? (yes/no)

Yes, the banner appeared perfectly fine. 👌🏻

Conclusion

Based on these results:

• The AUMID registration appears to be working correctly.
• Windows is capable of rendering toasts for com.karem.whatrust.
• However, whatRust does not seem to reach the notification code path when a new WhatsApp message arrives, since the diagnostic log never recorded commands::notify invoked.