Implement voting-engine outbox delivery
Add retryable idempotent delivery for voting-engine outbox events and migrate controller broadcasts/notifications to after-commit consumers with operational visibility for failures and retries. PR #4183 structural review (head 3c6524f1a3d4df98ded6bbec76b8905e443c8ad7), P2: commands persist OutboxEvent records but no delivery consumer exists. Broadcasts and integration calls still depend on controllers/jobs continuing successfully after commit. A crash or enqueue failure after an accepted poll start can leave the poll committed as ongoing without notifying voters; the persisted event currently provides no automatic recovery. Complete this before production cutover. Relevant: app/services/voting_engine/command_processor.rb:37; app/controllers/secretary/polls_controller.rb:47–53; docs/voting_engine_operations.md explicitly identifies durable delivery as separate work. Superseded: the active Rust architecture intentionally removed the voting outbox, event replication, NATS consumer and Rails projections. Rust state is queried directly; Turbo delivery is best effort and reload/reconnect is presentation recovery. Production observability and recovery checks remain required, but an outbox consumer must not be reintroduced.
Checklist
0 of 5 complete- Define idempotent outbox consumer and delivery state
- Implement retryable worker delivery keyed by event or receipt ID
- Move controller broadcasts and notifications to consumers
- Test failure, retry, replay, and duplicate delivery, including a poll start committed before process/enqueue failure: worker recovery must notify clients without resubmitting the command; rolled-back commands must emit no effects.
- Add operational visibility for pending and failed events
- Area
- Kaukus
- Kind
- Feature
- Priority
- Medium
- Task ID
tsk_zdaraph9uw- Updated