Stratara.Testing.Orleans
4.3.1
Prefix Reserved
See the version list below for details.
dotnet add package Stratara.Testing.Orleans --version 4.3.1
NuGet\Install-Package Stratara.Testing.Orleans -Version 4.3.1
<PackageReference Include="Stratara.Testing.Orleans" Version="4.3.1" />
<PackageVersion Include="Stratara.Testing.Orleans" Version="4.3.1" />
<PackageReference Include="Stratara.Testing.Orleans" />
paket add Stratara.Testing.Orleans --version 4.3.1
#r "nuget: Stratara.Testing.Orleans, 4.3.1"
#:package Stratara.Testing.Orleans@4.3.1
#addin nuget:?package=Stratara.Testing.Orleans&version=4.3.1
#tool nuget:?package=Stratara.Testing.Orleans&version=4.3.1
Stratara.Testing.Orleans
Derived. The behaviour described here is specified under
openspec/specs/. Those specifications are the source; this page explains and illustrates them.
Run the Orleans execution model in a test's own process. ExecutionModelTestHost starts one
silo clustered with itself, with reminders and the grain directory in memory, and the framework's
real write stack, portable commit-order reader, checkpoint store and intent store on an in-memory
SQLite database. Every period the model keeps as a reminder or a poll is shortened to seconds, so a
projection applies and a timer fires within a test. No cluster, no broker, no database server, no
Docker.
Builds on Stratara.Testing.EntityFrameworkCore.
Why run the real grains?
Because the registration is what a test should prove. Your handlers, projections, sagas, processes
and timer ports are registered with the calls production uses — AddStrataraAggregateGrains,
AddStrataraProjectionGrains, AddStrataraSagaGrains, AddStrataraDurableTimers,
AddStrataraOrleansCommandDispatcher — and run in the same grains, through the same mediator
pipeline, reading the store in commit order from a checkpoint.
Example
await using var host = await ExecutionModelTestHost.CreateAsync(services => services
.AddAggregatesFromAssemblyContaining<Account>()
.AddCommandHandlersFromAssemblyContaining<OpenAccountHandler>()
.AddProjectionsFromAssemblyContaining<BalanceProjection>()
.AddStrataraAggregateGrains()
.AddStrataraProjectionGrains());
await host.DispatchAsync(new OpenAccount(accountId, 100m)); // runs in the account's activation
await host.WaitForReadersAsync(); // every reader is at the store's head
Assert.Equal(100m, balances[accountId]);
Contents
ExecutionModelTestHost—CreateAsync(configure, options),DispatchAsync,WaitForReadersAsync,Timers,SeedAtHeadAsync,ResetAsync, the presetSessionandServices.IAsyncDisposable.ExecutionModelTestHostOptions— the periods (PollInterval250 ms,ReminderPeriod1 s,IntentGrace2 s,DrainPollingInterval1 s), the partition count (4), the start timeout, andBeforeStart, which runs before the silo starts — where a test appends history and seeds the readers at its head, as a deployment does while no silo runs. A value a test sets through a registration's own settings wins over the host's.StrataraTestReadDbContext— the read context that holds the checkpoints.
Share a host across a test class
Creating a host takes a few seconds. Share one through a class fixture and reset it between tests where one must not see another's state:
public sealed class ExecutionModelFixture : IAsyncLifetime
{
public ExecutionModelTestHost Host { get; private set; } = null!;
public async ValueTask InitializeAsync() =>
Host = await ExecutionModelTestHost.CreateAsync(services => services /* the roles */);
public ValueTask DisposeAsync() => Host.DisposeAsync();
}
ResetAsync runs the execution model's reset port on this host, where the silo keeps running: the timers
and the grain directory's entries go, and every registered reader is put at the store's head. The next
test's facts are applied, the last test's are not applied a second time, and WaitForReadersAsync returns
at once. The read models themselves are not emptied — empty or rebuild them in the fixture where a test
needs them clean.
Where the host stops
- One silo. Membership, reminders and the directory are in memory and not shared. What happens across silos — a kill, a role split, a takeover — is an integration test against real infrastructure.
- Test projects only. Referencing the package from a project that is not a test project fails
the build with
STRATARA1001;StrataraAllowTestSupportOutsideTests=trueopts out, as the sample does.CreateAsyncrefuses to run whereDOTNET_ENVIRONMENTorASPNETCORE_ENVIRONMENTstates an environment other thanDevelopment.
Dependencies
Stratara.Orleans,Stratara.Orleans.EntityFrameworkCore,Stratara.Testing.EntityFrameworkCoreMicrosoft.Orleans.Server,Microsoft.Extensions.Hosting
| Product | Versions Compatible and additional computed target framework versions. |
|---|---|
| .NET | net10.0 is compatible. net10.0-android was computed. net10.0-browser was computed. net10.0-ios was computed. net10.0-maccatalyst was computed. net10.0-macos was computed. net10.0-tvos was computed. net10.0-windows was computed. |
-
net10.0
- Microsoft.Extensions.Hosting (>= 10.0.11)
- Microsoft.Orleans.Server (>= 10.3.1 && < 11.0.0)
- Stratara.Orleans (>= 4.3.1)
- Stratara.Orleans.EntityFrameworkCore (>= 4.3.1)
- Stratara.Testing.EntityFrameworkCore (>= 4.3.1)
NuGet packages
This package is not used by any NuGet packages.
GitHub repositories
This package is not used by any popular GitHub repositories.
A correctness release. A projection replay could apply a stream's later fact before its first and
then fail on every attempt, leaving the read models it had emptied empty; the two backfills that
prepare existing history for the Orleans execution model's commit-order readers took the same wrong
order. Beyond that, the setting store no longer needs declared settings, and a setting or permission
vocabulary can be declared in parts.
**Upgrading:**
- **If you replay projections, upgrade.** A store in which one save appended several versions of a
stream can hold sequence numbers that run against those versions, and a replay over it could not
complete. No entry is rewritten and no migration is needed.
- **If you implement `IEventStreamRepository` yourself,** override
`GetManyAfterSequenceInStreamOrderAsync` to give your replay the same guarantee; the default keeps
sequence order.
- **If you backfilled a store for a commit-order reader before this release,** the Orleans migration
guide gives the query that tells whether that history holds a stream out of version order, and how
to repair it.
- **A host that declared an empty `SettingCatalog` as a workaround can drop it.** A host that
registers a catalog through a factory and then calls `AddSettingCatalog` or `AddPermissionCatalog`
now fails at registration instead of replacing that catalog.
- No schema change.
### Added
- **`IEventStreamRepository.GetManyAfterSequenceInStreamOrderAsync`**: a range of the store in the order a
replay applies it — each stream's entries in version order, the streams interleaved as their sequence numbers
interleave them, and the range extended until it no longer ends between two versions of one stream. The default
implementation returns `GetManyAfterSequenceAsync`, sequence order, so a repository of your own compiles and
behaves as before; override the member to give your replay the guarantee.
### Fixed
- **A projection replay applies each stream in version order.** A save does not number its entries in version
order — EF Core chooses the statement order and the identity column numbers the rows as they arrive — and the
replay walked the store by sequence number, so it met a stream's later fact before its first. A projection that
reports a missing preceding fact then failed the batch on every attempt, and because a replay empties the read
models first, each attempt left the read side empty. On a store where many saves wrote several versions of one
stream, no replay could complete. The replay now reads through the new repository member; a batch can hold more
entries than `Projections:BatchSize`. No entry is rewritten and no migration is needed.
- **Both commit-order backfills keep each stream in version order.** `CommitTransactionIdBackfill` could end a
batch between two versions of one stream, stamping the later one with the earlier transaction.
`PartitionCounterBackfill` handed out positions in sequence order, so every save it positioned that the store
had numbered against its versions was read inverted by the portable reader. Both now extend a batch until it no
longer ends inside a stream, and the portable backfill positions each stream's entries in version order.
History backfilled with an earlier version is not revisited, because checkpoints stand on its commit records and
positions; the Orleans migration guide gives the query that tells whether a store holds such a stream.
- **The setting store works without declared settings.** `AddSettingStore<TContext>()` and
`AddSettingStoreFromContextFactory<TContext>()` resolved the `SettingCatalog` inside a factory, so a
host that registered the store and `AddStrataraErasure()` but declared no settings built, passed
`ValidateOnBuild` and every start-up check, and failed on its first erasure with *No service for type
`SettingCatalog` has been registered*. The store now registers an empty catalog when none is declared:
the store works, erasure included, and reading any setting through `ISettingProvider` fails as
undeclared. The example on `AddStrataraErasure` was exactly that composition. A host that declared an
empty catalog as a workaround can drop it.
- **A second `AddSettingCatalog` or `AddPermissionCatalog` call no longer replaces the first.** Each
call registered a new catalog and the last one won, so a host declaring its vocabulary per module kept
only the last module's — the others' settings failed as undeclared and their permissions were denied
without a word. Every call now adds to the one registered catalog, in whichever order it runs relative
to the setting store. A setting name declared in two parts throws as a duplicate; a redeclared
permission has no effect and grants to one role accumulate. A catalog registered as a factory cannot be
added to, and the next call now throws `InvalidOperationException` saying so instead of replacing it.