Repository navigation
Stratara 4.1.0
The Orleans execution model ships as two new packages, Stratara.Orleans and
Stratara.Orleans.EntityFrameworkCore: one writer per aggregate across a cluster, accepted commands that
survive a crash, and projections and sagas that never miss a committed fact. Every host on the Entity
Framework store generates one migration when it upgrades, whether or not it adopts the execution model.
Telemetry type tags now carry the simple type name on every instrument, so a dashboard that filters the
projection, saga or conflict series on the qualified name needs its filter updated. Eight fixes land on
the retry, conflict, redaction and encryption work of 4.0.4, with one new warning to know about.
Added
- The Orleans execution model:
Stratara.OrleansandStratara.Orleans.EntityFrameworkCore.
Commands, projections, sagas, durable timers and singleton work run as virtual actors on an Orleans
10.3 cluster. One aggregate has one writer across the deployment; a command the execution model's
dispatcher accepts is recorded before the call returns and resumed after a crash, a bounded number of
times, through the same mediator pipeline as on the bus; projections and sagas read the store in
commit order from a checkpoint, so a crash costs latency and never a committed fact; singleton work
runs once per cluster without a lock; a failing entry stops its partition and is retried instead of
being dropped. Handlers, projections and sagas are unchanged, each role is adopted with one
registration after its composite, and both models can run side by side during a rollout. Every
setting is validated at start. See Choose an Execution Model, Migrate to the Orleans Execution
Model and Operate the Orleans Execution Model on the documentation site. - Schema additions — every host on the Entity Framework store generates a migration. The framework's
write context declaresevent_stream_entry.partition_position, thepartition_positiontable, on
PostgreSQLevent_stream_entry.commit_transaction_id, and theoutbox_entrycolumnsaggregate_id,
heavy,attempt_count,last_handed_over_at,kept_atandlast_failure; the read context declares
projection_checkpoint. They are part of the model whether or not a host adopts the execution model, so
every host onStratara.EventSourcing.EntityFrameworkCoregenerates and applies a migration after
upgrading — without it, appends and outbox writes fail on the missing columns. A store that never runs
the execution model carries them unfilled; on PostgreSQL an append also reads back the transaction id. - Composites without the bus-fed worker.
AddEventProjectionServices()andAddSagaServices()
register the projection and saga runtimes without their bus workers;AddProjectionHandlingand
AddSagaHandlingdo the same onIServiceCollection. - Every instrument name is a published constant.
ApplicationDiagnostics.Metricscarries a
…Nameconstant beside each instrument —EventsAppendedName,ProjectionEventsProcessedName,
SagasInFlightNameand the others — so a query or listener references the name instead of a literal.
ApplicationDiagnostics.MetricTags.TypeNameValuegives the value a type tag carries for a type name. LogEvents.Messaging.WorkerQueueDeclaredWithOtherArguments(108_112), the warning a RabbitMQ
worker logs when it uses an existing queue declared with other arguments.
Changed
event.typeandaggregate.typecarry the simple type name on every instrument. On
projection.events.processed,saga.events.processedandevent_source.append.conflictsthe tag
value changes from the assembly-qualified name (Shop.Orders.OrderPlaced, Shop.Orders) to the simple
name (OrderPlaced), the formevent_source.events.appendedalready used, so write and read series
join on the same value. A dashboard or alert that filters those three series on the qualified name
needs its filter updated; no instrument or tag name changes.AddAuthorizingCommandOutboxDispatcher()decorates whichever command dispatcher is registered, not
only the RabbitMQ one, and composes with a dispatcher registered after it.
Fixed
- RabbitMQ: changing the retry bounds no longer stops a worker from subscribing. A worker queue
carriesx-delivery-limitfrom the bounds it was first declared with, and RabbitMQ refuses a
redeclaration with a different value — so a deployment that changedMessageRetryfailed every
subscription withPRECONDITION_FAILED. An existing queue is now used as it is, and the bus logs
108_112naming it. From RabbitMQ 4.3 the old limit does not cut the new bounds short; before 4.3
a raised bound needs the drained queue deleted once. - Azure Service Bus: a subscription whose
MaxDeliveryCountis below the bounds no longer hides
its dead-lettering. Where the host can read the subscription, the bounds for it are lowered to
fit under the broker's limit, so the framework makes the move and it reaches108_110and
messaging.dead_lettered. The warning108_111now says so. A failure to read the subscription
of any kind other than cancellation ends the check instead of the subscription. - A unique violation is a concurrency conflict whatever exception type carries it. The event
source consulted the registeredIStoreConflictDetectors only for an Entity Framework
DbUpdateException, so a unit of work that surfaced the provider's exception unwrapped got a
persistence failure instead of aConcurrencyException. Every detector now sees the exception
as the save threw it, as its contract says. - Proxy credentials and response cookies are redacted from traces in the form the semantic
conventions name them. The HTTP client and ASP.NET Core enrichment callbacks replaced
http.request.header.proxy_authorizationandhttp.response.header.set_cookie, but the
OpenTelemetry semantic conventions keep the dash —proxy-authorization,set-cookie— so a host
that captured headers under those names exported the values. Both forms are redacted now. - The concurrency-conflict policy retries a conflict the event source reports. An append that
lost the race surfaces fromIEventSource.SaveChangesAsyncasConcurrencyException, and
ResilienceNames.ConcurrencyConflictretried onlyConcurrencyConflictException— so an
IResilientRequestwhose handler appends events ran once and failed on the first conflict. The
policy now retries both, and still nothing else. - A revoked encrypted field of a value type reads as its default instead of failing the object.
Deserialization wrote an unreadable field back as JSONnull, which adecimal,intor other
non-nullable value type cannot hold — so erasing a subject's key made every record with such a
field throw instead of degrading. The field now reads as the type's default, and the object's
other fields are recovered. InMemoryKeyStorekeeps a scope usable after its current version is revoked. Revoking the
current key left the scope pointing at a key that no longer existed, so the next
GetOrCreateCurrentKeyAsyncthrew. It now falls back to the highest remaining version, or creates
a new one, asEnvelopeFileKeyStoredoes.IAggregationService.AggregateAsyncno longer documentsfromVersionas a start version. The
parameter has never been honoured: a rebuild starts from the stream's beginning, or from the latest
snapshot at or belowtoVersion. Its documentation now says so; the signature is unchanged.