Today I finally tracked down a frustrating bug in our office-chat desktop app. When a user clicked a system notification, the app didn't open the right chat thread — or sometimes didn't open at all. It felt like a classic “works on my machine” issue, but it was happening for several users on Windows and macOS.
The app is built with Tauri (Rust backend) and Svelte (frontend). Notifications are triggered from the Rust side using the tauri-plugin-notification API. The click event is supposed to emit a custom event back to the frontend, which then navigates to the relevant conversation.
After digging in, I found two problems:
The event payload was missing the conversation ID. The Rust code was sending a generic
notification-clickedevent without any data, so the frontend had no idea which thread to open.Even when the payload was correct, the Svelte listener was attached too late. The notification click could fire before the Svelte app had fully mounted, so the event was lost.
For the first issue, I updated the Rust handler to include the conversation ID in the event payload. That was straightforward — just pass the ID along when creating the notification.
For the second, I moved the event listener registration into the onMount lifecycle of the root component, and also added a small queue in the frontend to buffer any events that arrive before the app is ready. That way, no click is ever dropped.
I also added a quick test with Postman to simulate the notification payload and verify the frontend routing logic. It’s not a full end-to-end test, but it caught a few edge cases.
The fix is now in a PR and I’m waiting for review. It’s a small change, but it makes the app feel much more responsive. If you’re building a Tauri app with notifications, double-check your event payloads and listener timing — those two are easy to overlook.
