Skip to content

Release v22.134.2

Choose a tag to compare

View all tags
@github-actions github-actions released this 20 Oct 12:45
v22.134.2
e46203c
This commit was created on GitHub.com and signed with GitHub’s verified signature.
GPG key ID: B5690EEEBB952194
Verified
Learn about vigilant mode.

Summary

Cratis.Chronicle, Cratis.Chronicle.AspNetCore and Cratis.Chronicle.Testing are updated from 19.90.0 to 19.99.1, picking up 19.90.1, 19.91.0, 19.91.1, 19.91.2, 19.92.0, 19.92.1, 19.92.2, 19.93.0, 19.93.1, 19.94.0, 19.95.0, 19.96.0, 19.97.0, 19.98.0, 19.99.0 and 19.99.1.

Added

  • Chronicle 19.91.0: The kernel accepts appends with an idempotency key (AppendOnce, AppendManyOnce and their named-tags variants): a retried append with the same key and content is reported as already appended instead of writing the event again, and the same key with different content is refused with a conflict. Clients can detect support through the idempotent-appends kernel capability (part of Cratis/Chronicle#4809)
  • Chronicle 19.92.0: IdempotencyKey, a key of 1 to 512 characters that identifies one logical append. Keys must not contain personal data. (part of Cratis/Chronicle#4809)
  • Chronicle 19.92.0: 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 Cratis/Chronicle#4809)
  • Chronicle 19.92.0: 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 Cratis/Chronicle#4809)
  • Chronicle 19.92.0: 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 Cratis/Chronicle#4809)
  • Chronicle 19.92.0: 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 Cratis/Chronicle#4809)
  • Chronicle 19.92.0: Documentation for appending once and appending many events once. (part of Cratis/Chronicle#4809)
  • Chronicle 19.94.0: The built-in reactor side-effect handlers append returned events with an idempotency key built from the delivery identity, the reactor's effect epoch and the event's position. A key you set yourself on an EventForEventSourceId is kept. See Duplicate protection for returned events. (part of Cratis/Chronicle#4809)
  • Chronicle 19.94.0: [Reactor("id", effectEpoch: n)] and [Reactor("id", "sequence", effectEpoch: n)] start a new key space for a reactor whose returned output changed; ReactorDelivery.EffectEpoch exposes it. The existing constructors are unchanged. (part of Cratis/Chronicle#4809)
  • Chronicle 19.94.0: ReactorDelivery.IdempotencyKeyFor("effect-name") derives a stable key for an effect you append yourself. (part of Cratis/Chronicle#4809)
  • Chronicle 19.94.0: Cratis.Chronicle.Testing advertises idempotent appends, so scenarios using the real side-effect handlers exercise keyed appends. (part of Cratis/Chronicle#4809)
  • Chronicle 19.96.0: authentication settings on the HTTP storage connection resolver: ClientCredentials (token endpoint, client id, secret and scope) and AzureCredential (managed identity, workload identity or default Azure credential, with a scope). Resolvers configured without authentication behave as before (Cratis/Chronicle#5154)
  • Chronicle 19.97.0: SQL storage now creates the MembershipVersions and MembershipEntries tables in the cluster database, the storage for a SQL Server or PostgreSQL backed Orleans membership table. Multi-node clustering on SQL storage is not enabled yet; that arrives with the clustering configuration in a later release (part of Cratis/Chronicle#5127)
  • Chronicle 19.98.0: Optional OAuth scope on webhook and external-service OAuth authorization, in the .NET client builders, the gRPC contracts and the Workbench forms. Existing registrations without a scope keep working unchanged (Cratis/Chronicle#5139)
  • Chronicle 19.99.0: The Testing client can drop the reply of a keyed append (AppendOnce, AppendManyOnce and their named-tag variants) with DropNext(DroppedReply.Append), so a scenario can lose the reply after the kernel committed the append and retry with the same idempotency key. (Cratis/Chronicle#5099)

Changed

  • Cratis.Chronicle, Cratis.Chronicle.AspNetCore and Cratis.Chronicle.Testing are updated to 19.99.1
  • Chronicle 19.92.0: 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 Cratis/Chronicle#4809)
  • Chronicle 19.92.0: 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 Cratis/Chronicle#4809)
  • Chronicle 19.92.2: The storage connection resolution documentation lists the supported Entra modes, explains that an access token from a resolver must not be combined with Authentication= or a password in the connection string, and shows Azure Database for PostgreSQL with a token. The clustering documentation states that single-node deployments must stop the old instance before starting the new one. (Cratis/Chronicle#5126)
  • Chronicle 19.93.0: The .NET client now logs a Warning at startup when a projection removes its root read model through a join (RemovedWithJoin at the root in a fluent, model-bound or explicit projection). Root removal through a join is not supported and removes nothing; the warning points to RemovedWith for root removal and RemovedWithJoin on a children collection. (part of Cratis/Chronicle#4263)
  • Chronicle 19.94.0: Against a kernel with idempotent appends, a reactor that returns different events for a delivery whose events are already appended now fails the partition instead of appending a duplicate. The failure message names the remedy: raise the reactor's effect epoch, or mark the handler [OnceOnly]. Build returned events from the triggering event and stable state, not from a fresh Guid or the current time. (part of Cratis/Chronicle#4809)
  • Chronicle 19.94.0: Against a kernel without idempotent appends, returned events are appended unkeyed as before and one warning is logged per reactor; a key the handler set itself throws IdempotentAppendsNotSupported. (part of Cratis/Chronicle#4809)
  • Chronicle 19.95.0: SQL storage serializes schema provisioning across kernel processes with a database lock, so several kernels starting at once against one SQL Server or PostgreSQL database no longer race to create or upgrade the same tables (Cratis/Chronicle#5137)
  • Chronicle 19.95.0: SQL storage persists observer in-flight events and handled counts in the database, so they survive a kernel restart and are shared between kernels using the same database (Cratis/Chronicle#5136)
  • Chronicle 19.95.0: Groundwork for running the kernel as a multi-node cluster on SQL storage (part of Cratis/Chronicle#5127)
  • Chronicle 19.96.0: The Chronicle server now uses Cratis Arc 22.131.0 (Cratis/Chronicle#5154)
  • Chronicle 19.96.0: Validation failures returned by the server's management commands now report member names in camelCase (for example name instead of Name), matching Arc's validation contract (Cratis/Chronicle#5154)
  • Chronicle 19.98.0: The kernel caches client-credentials access tokens per token endpoint, client, scope and secret, shares one in-flight token request between concurrent senders, refreshes a token shortly before it expires, and retries a webhook delivery once with a fresh token when the receiver answers 401 Unauthorized (Cratis/Chronicle#5139)
  • Chronicle 19.99.1: Azure Key Vault used as the encryption key store must allow purging deleted secrets: grant the purge permission and do not enable purge protection on that vault, otherwise erasing a subject fails. (Cratis/Chronicle#3674)

Fixed

  • Chronicle 19.90.1: Changing only the details text of a [ComplianceDetails]/[PII] or [Encrypted] marking on an existing event type no longer counts as an event schema change, so the kernel no longer refuses the registration with EventTypeSchemaChanged. A change of the compliance metadata type or the encryption scope, or an added or removed marking, still counts as a schema change. (Cratis/Chronicle#4660)
  • Chronicle 19.91.1: Projection and reducer writes to MongoDB that fail during a bulk flush are no longer silently dropped. Every affected partition is recorded as failed and retried, failed partitions carry the event source id instead of the read-model key, and a catch-up whose final flush has an unknown outcome fails instead of moving the observer past writes that may have been lost. (part of Cratis/Chronicle#4605)
  • Chronicle 19.91.2: A catch-up over many partitions no longer fails steps whose events were already delivered, or leaves the catch-up job running forever, when the per-step handled-event reports queue up on the observer. Reports are now cheap in-memory updates written together, a report resent after a timeout is not counted twice, a late report no longer fails a handled step, and any other step failure records a failed partition so it is retried. (part of Cratis/Chronicle#4954)
  • Chronicle 19.92.1: Releasing a read model composed in code no longer logs a "no subject could be resolved" warning when every subject-scoped ([PII] or secret) value on it is null. The warning still appears when a subject-scoped value is present and no subject can be resolved. (Cratis/Chronicle#4940)
  • Chronicle 19.92.1: A [NotProjected] member on a read model projected through IProjectionFor<T> no longer registers a second, empty model-bound projection for it, so the extra observer that stayed Disconnected is gone. (Cratis/Chronicle#4964)
  • Chronicle 19.92.2: Microsoft Entra ID authentication modes in SQL Server connection strings (Authentication=Active Directory Managed Identity, Active Directory Default, Active Directory Workload Identity, Active Directory Service Principal) now work. Since Microsoft.Data.SqlClient 7 these providers ship in Microsoft.Data.SqlClient.Extensions.Azure, which the kernel now includes. (Cratis/Chronicle#5126)
  • Chronicle 19.92.2: The SQL Server and PostgreSQL health checks now connect with the identity from storage connection resolution, so a kernel whose credentials or access token come from a resolver no longer reports itself unhealthy. (Cratis/Chronicle#5138)
  • Chronicle 19.93.1: A client whose event-store registration failed (for example on a schema rejection) no longer keeps retrying the registration in the background: the retry stops when creating the event store fails and when the client is disposed, so the event-store graph is no longer leaked. (part of Cratis/Chronicle#5053)
  • Chronicle 19.98.0: Testing an OAuth authorization from the Workbench now uses the configured scope, and a webhook is no longer sent with an empty Bearer header when no token could be acquired (Cratis/Chronicle#5139)
  • Chronicle 19.99.1: Provisioning an encryption key is now atomic on every key store. Two kernels that provision the same subject's key at once always end up using the same key: SQL and MongoDB no longer return a key that was never stored, HashiCorp Vault writes with check-and-set, and Azure Key Vault elects one key among concurrent writers. If the winning key cannot be read back, provisioning fails instead of encrypting with a key that would be lost. (Cratis/Chronicle#3745)
  • Chronicle 19.99.1: Erasing a subject on Azure Key Vault now purges every revision of the encryption key instead of only soft-deleting it, so the key cannot be recovered from the vault's deleted secrets. If the vault refuses the purge (purge protection, or a missing purge permission), erasure fails instead of reporting success. (Cratis/Chronicle#3674)
Assets 2
Loading