Repository navigation
Release v19.92.0
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)AppendOnceandAppendManyOnceonIEventSequenceandIEventLog, plusAppendOnceWithNamedTagsandAppendManyOnceWithNamedTags.AppendManyOncederives a key per event from the batch key withIdempotencyKey.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.OutcomeandAppendManyResult.Outcomesreport whether each event wasAppended,AlreadyAppendedorAlreadyAppendedAfterErasure.IdempotencyConflictsreports 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.SupportsIdempotentAppendstells you whether the connected kernel accepts keyed appends. Against a kernel that does not, keyed appends throwIdempotentAppendsNotSupportedbefore 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
IdempotentAppendsNotSupportedinstead of dropping the key. (part of #4809) - The new public types
IdempotencyKey,AppendOutcome,IdempotencyConflictReasonandIdempotencyKeyConflictlive inCratis.Chronicle.EventSequences; an application that declares a type with one of these names and imports that namespace needs to qualify it. (part of #4809)