HeiKyu/Rendezvous
2
0
Fork 0
Code Issues 27 Pull Requests Actions Packages Projects Releases Wiki Activity

Build atomic ephemeral state and define single-active availability semantics #6

New Issue
Open
opened 2026-07-15 10:04:16 +02:00 by Kyuubi · 2 comments
Kyuubi commented 2026-07-15 10:04:16 +02:00
Owner
Copy Link
Copy Source

Parent: #1
Depends on: #2, #3, #4

Outcome

Provide bounded, deterministic storage semantics for leases, endpoint observations, attempts, replay state, and expiry without introducing durable gameplay state.

Scope

  • Define store interfaces and atomic transitions for listings, leases, presence, join attempts, endpoint binding, replay/consumption, and revocation.
  • Implement the v1 single-process in-memory store with injectable monotonic/wall clocks and deterministic cleanup.
  • Define restart semantics: ephemeral state disappears, hosts re-register, and clients receive typed failures.
  • Bound every collection and queue with explicit overload behavior.
  • Define concurrency, idempotency, cancellation, clock-skew, drain, and partial-operation semantics.
  • Keep the abstraction suitable for a Redis-style TTL/CAS implementation if #18 later requires multiple instances.

Acceptance criteria

  • Deterministic tests cover renew/delete races, expiry, duplicate requests, concurrent endpoint binding, replay consumption, clock movement, and cancellation.
  • No expired/revoked record is observable through another path.
  • Store exhaustion sheds new work predictably without corrupting existing state.
  • Restart and graceful-drain behavior are documented and tested.
  • No database is required for the single-active MVP.
  • New joins fail closed whenever atomic authorization cannot be guaranteed.
Parent: #1 Depends on: #2, #3, #4 ## Outcome Provide bounded, deterministic storage semantics for leases, endpoint observations, attempts, replay state, and expiry without introducing durable gameplay state. ## Scope - Define store interfaces and atomic transitions for listings, leases, presence, join attempts, endpoint binding, replay/consumption, and revocation. - Implement the v1 single-process in-memory store with injectable monotonic/wall clocks and deterministic cleanup. - Define restart semantics: ephemeral state disappears, hosts re-register, and clients receive typed failures. - Bound every collection and queue with explicit overload behavior. - Define concurrency, idempotency, cancellation, clock-skew, drain, and partial-operation semantics. - Keep the abstraction suitable for a Redis-style TTL/CAS implementation if #18 later requires multiple instances. ## Acceptance criteria - Deterministic tests cover renew/delete races, expiry, duplicate requests, concurrent endpoint binding, replay consumption, clock movement, and cancellation. - No expired/revoked record is observable through another path. - Store exhaustion sheds new work predictably without corrupting existing state. - Restart and graceful-drain behavior are documented and tested. - No database is required for the single-active MVP. - New joins fail closed whenever atomic authorization cannot be guaranteed.
Kyuubi commented 2026-07-16 05:15:15 +02:00
Author
Owner
Copy Link
Copy Source

Starting implementation on codex/issue-6-atomic-state, stacked on the verified #2–#5 foundation. I’ll define engine-agnostic atomic store contracts and a bounded single-process implementation with deterministic clocks/cleanup, fail-closed authorization, explicit overload/drain/restart semantics, and race/idempotency/cancellation/clock-movement tests.

Starting implementation on `codex/issue-6-atomic-state`, stacked on the verified #2–#5 foundation. I’ll define engine-agnostic atomic store contracts and a bounded single-process implementation with deterministic clocks/cleanup, fail-closed authorization, explicit overload/drain/restart semantics, and race/idempotency/cancellation/clock-movement tests.
Kyuubi self-assigned this 2026-07-16 05:15:15 +02:00
Kyuubi commented 2026-07-16 05:33:11 +02:00
Author
Owner
Copy Link
Copy Source

Implemented and pushed on codex/issue-6-atomic-state at 02ca502.

Delivered:

  • an engine-internal atomic store contract covering listings/leases, authenticated host presence, compatible visible reads, join attempts, endpoint binding, replay consumption, revocation, availability, restart generation, and graceful drain;
  • a single-process bounded implementation with one auditable atomic transition boundary, injected monotonic/wall clocks, deterministic cleanup, stable client expiry timestamps, immutable snapshots, and secret fingerprints that redact themselves;
  • compare-and-swap lease renewal; owner-scoped idempotent registration/join creation; whole-endpoint host-presence refresh; first-binding-wins attempt endpoints; and one-time introduction/replay consumption;
  • fail-closed ServiceUnavailable, Draining, CapacityExceeded, Conflict, Expired, ReplayRejected, and tenant-hidden NotFound outcomes;
  • independent ceilings for listings, presence, attempts, replay, revocation, and idempotency plus atomic policy-provided publisher/tenant quotas with no partial insertion or eviction;
  • atomic cascade cleanup for expiry/revocation, empty-state restart semantics, a bounded drain window, readiness/shutdown integration, and ADR 0004 documenting concurrency, cancellation, clock movement, overload, partial-operation, restart, and future Redis CAS/TTL requirements.

Verification:

  • locked restore, formatter verification, Release solution build, generated OpenAPI drift check, and 78/78 tests passed;
  • deterministic tests cover renew/delete races, stale CAS, duplicate/conflicting requests, lease/presence/attempt/replay expiry, concurrent endpoint binding, one-time consumption, wall-clock movement, cancellation, every bounded pool, atomic quotas, revocation cascades, restart, drain, invalid default security values, and fail-closed unavailability;
  • a real Development server bound HTTP/UDP and /health/ready returned 200 with the state-store readiness gate active;
  • completion and multi-lens branch audits found no remaining actionable findings.

The issue remains open until the stacked branch is landed.

Implemented and pushed on `codex/issue-6-atomic-state` at `02ca502`. Delivered: - an engine-internal atomic store contract covering listings/leases, authenticated host presence, compatible visible reads, join attempts, endpoint binding, replay consumption, revocation, availability, restart generation, and graceful drain; - a single-process bounded implementation with one auditable atomic transition boundary, injected monotonic/wall clocks, deterministic cleanup, stable client expiry timestamps, immutable snapshots, and secret fingerprints that redact themselves; - compare-and-swap lease renewal; owner-scoped idempotent registration/join creation; whole-endpoint host-presence refresh; first-binding-wins attempt endpoints; and one-time introduction/replay consumption; - fail-closed `ServiceUnavailable`, `Draining`, `CapacityExceeded`, `Conflict`, `Expired`, `ReplayRejected`, and tenant-hidden `NotFound` outcomes; - independent ceilings for listings, presence, attempts, replay, revocation, and idempotency plus atomic policy-provided publisher/tenant quotas with no partial insertion or eviction; - atomic cascade cleanup for expiry/revocation, empty-state restart semantics, a bounded drain window, readiness/shutdown integration, and ADR 0004 documenting concurrency, cancellation, clock movement, overload, partial-operation, restart, and future Redis CAS/TTL requirements. Verification: - locked restore, formatter verification, Release solution build, generated OpenAPI drift check, and 78/78 tests passed; - deterministic tests cover renew/delete races, stale CAS, duplicate/conflicting requests, lease/presence/attempt/replay expiry, concurrent endpoint binding, one-time consumption, wall-clock movement, cancellation, every bounded pool, atomic quotas, revocation cascades, restart, drain, invalid default security values, and fail-closed unavailability; - a real Development server bound HTTP/UDP and `/health/ready` returned 200 with the state-store readiness gate active; - completion and multi-lens branch audits found no remaining actionable findings. The issue remains open until the stacked branch is landed.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Kyuubi schmidt.florian (Florian Schmidt)
No Assignees Kyuubi
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: HeiKyu/Rendezvous#6
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?