Pillar v0.3.0 — The Control Plane Acts

v0.3.0 — The Control Plane Acts

Iteration 1 taught Pillar to see the fleet. Iteration 2 taught it to decide. This release teaches it to act: players are placed, moved, messaged, and resources are locked — all through the existing envelope machinery, with zero Redis I/O on the login hot path.

Highlights

Player routing at login

Joining players are placed on the configured entry role via the Iteration 2 placement engine (eligibility hard caps → P2C selection → in-flight reservation). The entire decision reads three in-memory volatile snapshots and touches Redis zero times. When no node is eligible, the connection is refused with a localizable message.

Cross-server player movement

Any game server can request Pillar to move a player to a specific server or to a role (placement decides the best node). The proxy actuates the connection and reports the outcome back to the requester: SUCCESS, NO_ELIGIBLE_NODE, PLAYER_OFFLINE, UNKNOWN_TARGET, or CONNECTION_FAILED.

Player and network messaging

SEND_PLAYER_MESSAGE delivers a MiniMessage component to a named player wherever they are on the network. BROADCAST delivers to every connected player. The proxy resolves targets; the sender never needs to know which server a player is on.

Generic lease primitive

LeaseService.acquire(resource, owner, ttl) provides mutual exclusion across the fleet via atomic SET NX PX + owner-checked Lua renew/release. SkyBlock islands, minigame arenas, unique bosses — any resource that needs exactly one owner. No Redlock; guarantee boundary documented in ADR-0008.

In-memory health cache

HealthRegistry refreshes a volatile snapshot of the fleet's health on a background loop, powering the zero-I/O login path and the automatic least-connections fallback when telemetry degrades.

withResource consolidation

RedisConnector.withResource(fn) replaces duplicated getResource + exception handling across all Redis adapters, sealing the raw JedisPool inside the lifecycle package.

---

End of this release = MVP (FR-01 through FR-07).

What's next

Iteration 4 — Production Hardening: pending-message recovery from dead consumers (XAUTOCLAIM), defined degraded-mode behavior and self-recovery, /pillar doctor with decision telemetry and placement explanations, and failure drill scripts.