Handler functions in side_effects.rs interleave domain mutations (DB writes) with notification emission (system messages, NIP-29 discovery events, membership notifications, cache invalidation). For example, handle_put_user calls db.add_member() then immediately emits 3 different notification types. handle_remove_user calls db.remove_member() then emits a system message and discovery events. This coupling means: (1) domain mutations cannot be tested without the notification infrastructure, (2) notification failures can leave the system in an inconsistent observed state, (3) adding a new mutation path requires remembering all the notifications that should accompany it. Separating "what happened" (the mutation) from "tell everyone" (notifications) — via an event/command pattern or simple function decomposition — would improve testability and reduce the risk of inconsistent notification coverage. Priority: Low — larger architectural improvement, do after the buzz-db structural work is complete.
🤖 AI review update (2026-08-23)
Treat this as a design task before implementation. Simple function decomposition does not solve partial failure: classify every side effect as transactional, durable/retryable (for example via an outbox), or explicitly best-effort; define idempotency, ordering, retry, and recovery behavior. Then extract one mutation flow as a proving slice with failure-injection tests.
Handler functions in
side_effects.rsinterleave domain mutations (DB writes) with notification emission (system messages, NIP-29 discovery events, membership notifications, cache invalidation). For example,handle_put_usercallsdb.add_member()then immediately emits 3 different notification types.handle_remove_usercallsdb.remove_member()then emits a system message and discovery events. This coupling means: (1) domain mutations cannot be tested without the notification infrastructure, (2) notification failures can leave the system in an inconsistent observed state, (3) adding a new mutation path requires remembering all the notifications that should accompany it. Separating "what happened" (the mutation) from "tell everyone" (notifications) — via an event/command pattern or simple function decomposition — would improve testability and reduce the risk of inconsistent notification coverage. Priority: Low — larger architectural improvement, do after the buzz-db structural work is complete.🤖 AI review update (2026-08-23)
Treat this as a design task before implementation. Simple function decomposition does not solve partial failure: classify every side effect as transactional, durable/retryable (for example via an outbox), or explicitly best-effort; define idempotency, ordering, retry, and recovery behavior. Then extract one mutation flow as a proving slice with failure-injection tests.