Skip to content

Release v19.92.0

Choose a tag to compare

@github-actions github-actions released this 19 Oct 16:10
70e3b3f

The .NET client can now append events once: give an append an idempotency key, and retrying it after an unknown outcome never stores the event twice.

Added

  • IdempotencyKey, a key of 1 to 512 characters that identifies one logical append. Keys must not contain personal data. (part of #4809)
  • AppendOnce and AppendManyOnce on IEventSequence and IEventLog, plus AppendOnceWithNamedTags and AppendManyOnceWithNamedTags. AppendManyOnce derives a key per event from the batch key with IdempotencyKey.ForIndex. (part of #4809)
  • EventForEventSourceId.IdempotencyKey, so a batch that spans event sources can key each event, and keyed and unkeyed events can be mixed in one batch. (part of #4809)
  • AppendResult.Outcome and AppendManyResult.Outcomes report whether each event was Appended, AlreadyAppended or AlreadyAppendedAfterErasure. IdempotencyConflicts reports a key reused for different content or event generation, or a match that can no longer be checked. Observers in the client are notified only for events that were actually appended. (part of #4809)
  • IEventSequence.SupportsIdempotentAppends tells you whether the connected kernel accepts keyed appends. Against a kernel that does not, keyed appends throw IdempotentAppendsNotSupported before anything is sent. (part of #4809)
  • Documentation for appending once and appending many events once. (part of #4809)

Changed

  • Idempotency keys are refused on events staged in a unit of work and on appends that carry effect receipts; those appends throw IdempotentAppendsNotSupported instead of dropping the key. (part of #4809)
  • The new public types IdempotencyKey, AppendOutcome, IdempotencyConflictReason and IdempotencyKeyConflict live in Cratis.Chronicle.EventSequences; an application that declares a type with one of these names and imports that namespace needs to qualify it. (part of #4809)