PlayerLease

Remarks

⚠ The epoch is the whole mechanism. Two realms cannot both hold epoch n: the second asker gets n+1 and the first is told its lease is dead, and a grain taking one turn at a time is what makes that atomic rather than merely likely. Every durable write names its epoch, so a duplicate arriving late is a no-op rather than a second grant.

A realm that has lost its lease keeps simulating — doc 27 is explicit that a lease loss mid-combat must be survivable — and buffers its durable mutations until the lease returns or the transfer hands them over.

Fields and properties (4)

• public bool Granted

  Whether the asker holds it.

• public long Epoch

  Which epoch. Monotonic per player, and never reused.

• public ShardId Holder

  Which shard holds it, granted or not.

• public DateTimeOffset Expires

  When it lapses without a renewal.

Methods (1)

• public PlayerLease(bool Granted, long Epoch, ShardId Holder, DateTimeOffset Expires)

  Whether a realm may write a player's durable state. ADR-021.

Used by (8)

• ClusterFleetDirectoryVixen.Live.Gate
• ClusterSerializationTestsVixen.Live.Cluster.Tests
• FakePlayerVixen.Live.Realm.Cluster.Tests
• IPlayerGrainVixen.Live.Cluster
• PlayerGrainVixen.Live.Orchestrator
• PlayerLeaseStateVixen.Live.Orchestrator
• PlayerLeaseTestsVixen.Live.Orchestrator.Tests
• RealmClusterVixen.Live.Realm.Cluster