Skip to main content

Module os_notify

Module os_notify 

Source
Expand description

Cross-platform best-effort desktop notifications.

Each backend shells out to the native binary (notify-send / osascript / powershell). Failures are swallowed — we’d rather lose a toast than crash the caller. Used by both wire notify (inbox events) and the daemon’s pending-pair tick (SAS-ready, pair-confirmed).

§Once-only across every wire process on the host

Pre-v0.14.2: dedup was an in-process Mutex<HashMap> with 30s TTL. That fell apart catastrophically once #170’s --all-sessions supervisor put 134 wire daemons on a single box: every daemon polled its own inbox, every daemon fired its own toast, the operator saw the same “pair complete” notification 134 times within seconds.

v0.14.2: every toast — both toast (now content-keyed) and toast_dedup (explicit-key) — first acquires a process-shared “first-emit” claim via an atomic O_CREAT|O_EXCL filesystem touch file under <cache_dir>/wire/toast-dedup/<sha256(key)>.touch. The filesystem is the dedup primitive — no flock, no race window. Once a touch file exists, no wire process anywhere on the host re-emits the same toast — ever. Operators who want to reset (e.g., to re-see a notification class after a code change) rm -rf the dir.

The in-process Mutex<HashMap> survives as a fast-path inside one process so the per-toast fs-stat doesn’t dominate the loop, but the filesystem claim is the actual guarantee.

Functions§

toast
Bare toast — fires once per (title, body) content across every wire process on the host. Defers to toast_dedup with a content-hash key so legacy call sites that don’t have a stable event-id key still get the cross-process once-only guarantee.
toast_dedup
Idempotent variant of toast: emits at most once per key, forever, across every wire process on the host.