Moderation notice writer: fence resurface, fix hide-clear/dedup ordering, publish snapshot
- Dominant language
- Rust
- Stars
- 32.7k
- Forks
- 4.3k
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 253
Description
Follow-up flagged during review of #6713 (DM resurfacing). This is **pre-existing** code not touched by that PR (`moderation_notices.rs` is not in its diff), tracked separately.
## Problem
`send_moderation_notice` clears the recipient hide **before** duplicate detection (`crates/buzz-relay/src/handlers/moderation_notices.rs:121-142`), while notice insertion happens later (`moderation_notices.rs:157-175`):
- A delivered notice → user re-hides → retry of the same `moderation_source` clears the newer hide, then returns as a duplicate **without accepting new activity**.
- A failure after the clear but before insertion has the same destructive shape (visibility mutated with no accepted message).
- The accepted path ends at insert/fan-out and never invokes the owner snapshot publisher or the causally fenced resurface helper, so snapshot consumers can stay hidden after a genuinely new safety notice.
## Proposed work
- Move the hide-clear **after** duplicate detection so a duplicate-after-rehide is a no-op.
- Ensure no pre-insert failure can mutate visibility (make acceptance + fenced resurface atomic).
- Use the same causally fenced resurface helper as ordinary ingest / workflow send.
- Publish a visibility snapshot on accepted notices.
## Acceptance / tests
- Duplicate-after-rehide is a no-op (newer hide preserved).
- Pre-insert failure performs no visibility clear (rollback / no-clear).
- Accepted new notice updates canonical visibility **and** publishes the snapshot.
Ref: Jude review at head `d28c8b0f4`, item #2. https://github.com/block/buzz/pull/6713
Contributor guide
Assessment
This issue has not been assessed yet.