Skip to content

Require reliable per-backend vote delivery - #80

Draft
remdui wants to merge 58 commits into
mainfrom
agent/reliable-vote-delivery
Draft

Require reliable per-backend vote delivery#80
remdui wants to merge 58 commits into
mainfrom
agent/reliable-vote-delivery

Conversation

@remdui

@remdui remdui commented Aug 1, 2026

Copy link
Copy Markdown
Member

Summary

Makes the persistent per-backend outbox the only ProxyFeatures Votifier transport and pairs with HauntedMC/ServerFeatures#87.

Every configured Velocity backend receives an independent durable Redis stream and local delivery obligation. Offline targets remain queued for up to 24 hours and recover through paced replay, while available targets and new live votes continue independently.

Single supported architecture

  • durable Redis messaging is required when Votifier starts
  • redis.delivery.servers is a required non-empty YAML list
  • every configured target must be an exact registered Velocity identifier matching [A-Za-z0-9_.-]{1,64}
  • every backend receives a private stream derived from redis.channel and redis.delivery.stream_pattern
  • the complete target batch is persisted before any publication attempt
  • no broadcast stream, legacy channel, transport enable flag, dual publication, CSV target parsing, mode selector, alias, or empty-list fallback remains

Reliability guarantees

  • persists one independent obligation per backend
  • survives proxy restarts through a versioned atomically replaced queue file
  • distinguishes malformed queue data from transient filesystem failures
  • pauses publication while the durable snapshot cannot be written
  • keeps the original event ID across Redis retries and queued replay
  • refreshes only the replay payload timestamp
  • drains one queued vote at a time per recovered backend with configurable spacing
  • recovers different backends concurrently
  • allows new live votes to progress during backlog recovery
  • enforces per-backend and global capacity without evicting in-flight records
  • validates all configured targets against Velocity before starting
  • closes and persists the outbox during feature shutdown

Configuration

Votifier:
  enabled: true
  redis:
    channel: proxy.votifier.vote
    publish_retry_attempts: 8
    publish_retry_delay_millis: 1000
    delivery:
      servers:
        - survival
        - skyblock
      stream_pattern: "{channel}.{server}"
      max_age_hours: 24
      retry_check_seconds: 15
      replay_delay_millis: 500
      ping_timeout_millis: 2000
      max_pending_per_server: 10000
      max_pending_total: 50000
      queue_file: votifier-delivery-queue.bin

This publishes to proxy.votifier.vote.survival, proxy.votifier.vote.skyblock, and so on.

Paired ServerFeatures configuration

server_name: survival

Votifier:
  enabled: true
  channel: proxy.votifier.vote
  stream_pattern: "{channel}.{server}"
  consumer_group: ""

VoteReward:
  enabled: true

Deploy both PRs together. The configured proxy target and backend server_name must be the same Velocity identifier.

Validation

Coverage includes queue persistence and corruption handling, offline recovery, refreshed replay timestamps, immutable event identity, persistence failure recovery, expiry, capacity enforcement, target validation, shutdown, and live-vote progress during blocked backlog replay.

The final head must pass lint, Java 25 Maven Verify, unit/integration tests, JaCoCo checks, and bundled Velocity acceptance before merge.

Documentation

Updates the feature guide for the mandatory private-stream architecture, exact backend identifier contract, failure behavior, operations, and deployment.

@remdui remdui changed the title Make backend vote delivery reliable Require reliable per-backend vote delivery Aug 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant