Part of #5118 (compliance wave growth), epic #5110.
AsyncDaemonCompliance rebuilds once, and RebuildConcurrencyCapCompliance pins the cap resolution. The rebuild and catch-up semantics are still tested independently in both repos, and they are the behaviors most often reported as bugs across both products.
Everything runs through JasperFx.Events.Daemon.IProjectionDaemon (RebuildProjectionAsync, StartAgentAsync, StopAgentAsync, StartAllAsync, WaitForNonStaleData), which the fixture already exposes via StartDaemonAsync() and WaitForNonStaleProjectionDataAsync(TimeSpan).
Seam additions required
Minimal — likely none for the single-tenant cases. The per-tenant rebuild cases need the tenant-scoped session and TenancyStyle from the conjoined tenancy issue, so sequence this one after it (or scope the per-tenant cases out and file them as a follow-up).
What each store tests today
| Marten |
Polecat |
Aggregation/rebuilding_a_single_stream_projection.cs |
Daemon/per_tenant_rebuild_tests.cs |
Aggregation/querying_with_non_stale_data.cs |
Daemon/async_daemon_tests.cs |
DaemonTests catch-up / subscribe-from tests |
Daemon/projection_progression_tests.cs |
rebuild_concurrency_cap_resolution.cs (already lifted) |
Daemon/read_projection_progress_extended_tests.cs |
Scope
New ProjectionRebuildCompliance suite:
- Rebuild replaces existing projected documents rather than duplicating them
- Rebuild after the projection's logic changed produces the new shape for old events
- Rebuilding one projection leaves other projections' progress untouched
- Rebuild of an empty event store is a no-op that still completes
- Catch-up: events appended while the daemon is stopped are processed on restart, exactly once
WaitForNonStaleProjectionDataAsync returns only after the shard has actually reached the high-water mark- Progress is recorded and readable after a rebuild (shared
AllProjectionProgress)
- Per-tenant rebuild affects only that tenant (sequence after the conjoined tenancy issue)
Explicitly out of scope: high-water detection internals, node distribution, HotCold, and the sharded/partitioned rebuild paths — all storage- or topology-specific.
Acceptance
- Suite enrolled in both stores, zero capability gates for the single-tenant cases
- Originals retired for the absorbed behavior in both repos
Part of #5118 (compliance wave growth), epic #5110.
AsyncDaemonCompliancerebuilds once, andRebuildConcurrencyCapCompliancepins the cap resolution. The rebuild and catch-up semantics are still tested independently in both repos, and they are the behaviors most often reported as bugs across both products.Everything runs through
JasperFx.Events.Daemon.IProjectionDaemon(RebuildProjectionAsync,StartAgentAsync,StopAgentAsync,StartAllAsync,WaitForNonStaleData), which the fixture already exposes viaStartDaemonAsync()andWaitForNonStaleProjectionDataAsync(TimeSpan).Seam additions required
Minimal — likely none for the single-tenant cases. The per-tenant rebuild cases need the tenant-scoped session and
TenancyStylefrom the conjoined tenancy issue, so sequence this one after it (or scope the per-tenant cases out and file them as a follow-up).What each store tests today
Aggregation/rebuilding_a_single_stream_projection.csDaemon/per_tenant_rebuild_tests.csAggregation/querying_with_non_stale_data.csDaemon/async_daemon_tests.csDaemonTestscatch-up / subscribe-from testsDaemon/projection_progression_tests.csrebuild_concurrency_cap_resolution.cs(already lifted)Daemon/read_projection_progress_extended_tests.csScope
New
ProjectionRebuildCompliancesuite:WaitForNonStaleProjectionDataAsyncreturns only after the shard has actually reached the high-water markAllProjectionProgress)Explicitly out of scope: high-water detection internals, node distribution, HotCold, and the sharded/partitioned rebuild paths — all storage- or topology-specific.
Acceptance