PlayerLeaseState

Remarks

⚠ There is no lock in this file and there must never be one. What makes this correct is that PlayerGrain takes one turn at a time; the moment somebody adds a lock, the reason becomes "we remembered to" rather than "the runtime guarantees it", and the next method somebody adds will not remember.

The epoch is monotonic and never reused. A realm that has been superseded discovers it on its next renewal, and every durable write names the epoch it was made under — so a write arriving late from a realm that has already lost is a no-op rather than a conflict to resolve.

⚠ Durable state is not here. Doc 27 § Persistence puts inventory and currency behind IPlayerRepository rather than in grain storage, precisely so it can be queried by the support tool, the economy dashboard and the analytics job. This is coordination — the lease and where the player is — which is the half a transfer needs before it can be written. The repository is L3.

Fields and properties (2)

• public ShardId Holder

  Which shard this character is on, as far as the cluster knows.

• public bool IsHeld

  Whether anybody currently holds it.

Methods (5)

• public PlayerLeaseState(LeaseOptions? options = null)

  Stands one up.

• public PlayerLease Acquire(ShardId shard)

  Takes the lease, superseding whoever held it.

• public PlayerLease Renew(ShardId shard, long presented)

  Says the holder is still alive.

• public void Release(ShardId shard, long presented)

  Gives it back. A stale epoch is ignored rather than refused.

• public PlayerLease Current()

  Who holds it, without taking it.

Used by (5)

• FakeClusterVixen.Live.Realm.Cluster.Tests
• FakePlayerVixen.Live.Realm.Cluster.Tests
• PlayerGrainVixen.Live.Orchestrator
• PlayerLeaseTestsVixen.Live.Orchestrator.Tests
• RealmClusterTestsVixen.Live.Realm.Cluster.Tests