One event can produce several identical notices — spawn_recall reports from both its triggers, and nothing deduplicates the list

[ErwanLegrand]

What happens

One event can produce several identical notices. Two instances, both observed on the reference
machine during FR-UI-070's manual run (2026-08-27):

Missing file reference on project reload (step 15). One deleted .nam, two identical notices:

state.reference.not_found: The file "{display_name}" (hash {hash}) could not be found. (nam_02.nam (hash f3ee3a69…))
state.reference.not_found: The file "{display_name}" (hash {hash}) could not be found. (nam_02.nam (hash f3ee3a69…))

spawn_recall has two deliberate triggers — crates/namir-clap/src/state_ext.rs:61 when the host
loads state, and crates/namir-clap/src/audio.rs:178 as activation's replay. Both comments
anticipate both running ("replay onto it too"; "most hosts load state before the first
activate()"). Each pushes its own notice at crates/namir-clap/src/worker_jobs.rs:139, and nothing
deduplicates. The replay being idempotent does not make its reporting idempotent.

Device removal (step 8). Two app.audio_io.device_lost notices, one per direction — and
indistinguishable from each other, because {direction} is never substituted (#15).

Consequence

Compounds the undismissable-notice issue filed alongside this one: in the plugin these are two rows
that cannot be removed, not one.

Fix

Deduplicate on push — same code and same detail already present means no second row — or have
the recall report only on a state transition rather than on every replay. The device case wants the
direction rendered as well, which #15 covers.

Evidence

docs/manual-tests/fr-ui-070-non-modal-error-notices.md, executed run, finding 5.

[ErwanLegrand]

FIXED — before #145, at M14 (0a993da). Deduplicate-on-push was the route taken.

namir_ui::push_deduplicated (crates/namir-ui/src/notices.rs:169) appends unless an identical notice is already showing. Identity is (code.id, detail) — two notices a user cannot tell apart are one notice — and the existing entry is kept rather than replaced, so a notice's id, and therefore whatever the user is about to click, stays stable while it is on screen.

It lives in namir-ui, the one crate both shells already depend on, rather than as a copy in each; both call it (crates/namir-app/src/host.rs:608, crates/namir-clap/src/shared.rs:345), so spawn_recall's two deliberate triggers now produce one row.

The namir-clap side records the interaction explicitly at worker_jobs.rs:255 and :284, where the second report is folded into the first.

The device-removal instance is fixed from both directions: the two app.audio_io.device_lost notices are now distinguishable because {direction} is substituted (#15), and both directions' streams are stopped from one classification rather than reporting independently (#24, d236e00) — its test asserts notices.len() == 1 and that a second frame or a second report cannot double-report a path already gone.

---

Generated by Claude Code