[ravarora2]

Summary

Make new stream/forum messages and replies respect the user-deletion restrictions added in #8632. HTTP and WebSocket writes check restrictions inside the transaction that persists the message. A restricted sender receives a fixed rejection; rejected replies do not change thread counters.

The writer uses shared identity locks through commit. It resolves agent ownership from PostgreSQL, locks the owner and signer, and rechecks ownership after waiting. Restrictions still apply after a profile is deleted or recreated. Agent-owner assignment now coordinates with those locks and refuses restricted owners or agents.

This is a partial serving integration: kinds 9, 40002, 45001, and 45003. It adds no migration, trigger, function, foreign key, backfill, or new batch-read API. Other writes and external-work draining remain follow-ups. Do not enable real fencing until all required paths are protected and deployed on every writer.

Implementation and coverage: user-deletion-message-fencing.md.

Related issue

Part of BUZZ-413. Follows merged #8632. No duplicate message-fencing PR found; #8489 covers workflow scaffolding and #8645 covers owned-community handlers.

Testing

Passed 116 selected PostgreSQL regressions covering message persistence, ownership, fences, and community deletion. The additional local-relay regression passed through HTTP over TCP and the WebSocket EVENT handler, including unchanged counters after rejected replies.

Mutation check: temporarily removing both production guard calls made the restriction regression fail because it accepted a fenced message. Both calls were restored before final validation.

To reproduce the focused behavior with test PostgreSQL and Redis configured: scripts/postgres-test-run.sh -p buzz-db -p buzz-relay --lib -E 'test(/user_deletion_write_guard/) | test(/user_deletion_message/)'.

All normal pre-push hooks and the full local just ci run passed.

The full just test run had one failure: composition_tests::composition_log_does_not_leak_issuer_url missed an expected warning in captured logs. The same compiled test passed when rerun alone. Every other test group, including workspace integration tests, passed. This log-capture failure also occurred during validation of #8632; no relay logging code is changed here.

This remains a draft pending human validation.

Generated with Codex

[presentyourlove]

Rebase & Conflict Resolution Report for PR #8658

Target PR: block/buzz#8658 — BUZZ-413: Fence stream and forum message writes
Author: @ravarora2 (Ravneet Arora)
Branch: fix/fence-stream-forum-writes-8658
Commit: 59097c94ca0fcb615988facc6877cdc467449c7d
Patch: 59097c94ca0fcb615988facc6877cdc467449c7d.patch

---

1. Problem & Root Cause

PR #8658 was marked as dirty (mergeable: false) on GitHub due to conflicts introduced when commit d6196a16c1 (#8237, revoke invitations and restrict claims) merged into main:

1. crates/buzz-db/src/error.rs:

   • main added InviteRestricted and InviteOwnerMismatch variants.
   • PR BUZZ-413: Fence stream and forum message writes #8658 added UserDeletionRestricted.
   • Resolution: Kept all variants so invitation restriction handling and user deletion restriction errors coexist seamlessly.

2. crates/buzz-db/src/store/user.rs:

   • In set_agent_owner_with_operation:
     • main added crate::relay_invite::lock_admission(tx.conn(), community_id).await?; to acquire the invitation admission lock on community write transactions.
     • PR BUZZ-413: Fence stream and forum message writes #8658 added tx.guard_agent_owner_assignment(agent_pubkey, owner_pubkey).await?; to verify user deletion fences and lock agent/owner identities.
   • Resolution: Kept both locks in canonical lock hierarchy order:

     let mut tx = crate::begin_community_write_transaction(pool, community_id, operation).await?;
     crate::relay_invite::lock_admission(tx.conn(), community_id).await?;
     tx.guard_agent_owner_assignment(agent_pubkey, owner_pubkey).await?;

     This ensures invitation admission and claim restrictions are enforced, user deletion fences guard agent ownership changes, and the conditional update remains atomic without deadlock.

---

2. GitHub PR Comment Draft (for @ravarora2)

Hi @ravarora2,

I rebased PR #8658 onto the latest `main` branch to resolve the merge conflict with commit `d6196a16c1` (#8237, *revoke invitations and restrict claims*):

- In `crates/buzz-db/src/error.rs`: Preserved both the new invitation restriction error variants (`InviteRestricted`, `InviteOwnerMismatch`) and `UserDeletionRestricted`.
- In `crates/buzz-db/src/store/user.rs`: In `set_agent_owner_with_operation`, preserved `lock_admission` alongside `guard_agent_owner_assignment` in canonical order so both invitation admission gating and user-deletion ownership fencing are held before the atomic `UPDATE`.

You can pull the rebased commit directly into your branch:

```bash
git fetch https://github.com/presentyourlove/buzz.git fix/fence-stream-forum-writes-8658
git rebase 59097c94ca0fcb615988facc6877cdc467449c7d

Or apply the patch:

curl -sL https://github.com/presentyourlove/buzz/commit/59097c94ca0fcb615988facc6877cdc467449c7d.patch | git am