IdempotencyKey

Remarks

⚠ Derived from the operation, never generated. Doc 27 § Persistence is explicit about this and it is the whole of the mechanism: a key a caller mints fresh per attempt is a different key on the retry, so the second attempt is a second trade. The key has to be something both attempts compute to the same value — the auction's id, the mail's id, the quest's id — which means it is a fact about what is being done rather than about this call.

The player is in the key because Operation is only unique within whatever minted it, and a mail id and an auction id could collide across two subsystems that never heard of each other. Kind is in it for the same reason one level up.

Fields and properties (4)

• public PlayerKey Player

  Whose operation. The one whose lease authorises it.

• public string Kind

  What sort of operation. Null only on default.

• public string Operation

  Which one. Null only on default.

• public bool IsValid

  Whether this names an operation at all.

Methods (4)

• public IdempotencyKey(PlayerKey Player, string Kind, string Operation)

  What makes a retry write nothing the second time.

• public bool Equals(IdempotencyKey other)

  Whether two keys name the same operation.

• public override int GetHashCode()

  Returns the hash code for this instance.

• public override string ToString()

  Returns the fully qualified type name of this instance.

Used by (8)

• ConservationTestsVixen.Live.Persistence.Tests
• LedgerAccountTestsVixen.Live.Persistence.Tests
• LedgerEntryVixen.Live.Persistence
• LedgerIntentVixen.Live.Persistence
• LedgerQueryVixen.Live.Persistence
• LedgerTestsVixen.Live.Persistence.Tests
• MemoryPersistenceVixen.Live.Persistence
• SqlPersistenceVixen.Live.Persistence