Repository navigation
#4751: regression test for async composite catch-up under sharded + tenant-partitioned - #4767
Merged
Merged
Conversation
…ant-partitioned Locks in the fix from #4764. Under MultiTenantedWithShardedDatabases + UseTenantPartitionedEvents, an async CompositeProjection was not driven to a non-stale state by the normal daemon catch-up path (StartAllAsync + WaitForNonStaleData) — the member read models stayed empty after catch-up returned. Root cause was shared with #4761: WaitForNonStaleData's "caught up" check could be satisfied by the HighWaterMark rows alone, without requiring the composite's per-tenant projection-progression row. #4764 fixed that. This test pins the behavior: a sharded, tenant-partitioned composite must materialize BOTH stages via the async daemon (not just via RebuildProjectionAsync). Passes on JasperFx 2.13.0 (the merged #4764 fix is sufficient; the defensive JasperFx ExecutionStage guard from #457 is a separate invariant assertion that rides the next routine JasperFx bump). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This was referenced Jun 19, 2026
Closed
This was referenced Jun 26, 2026
This was referenced Jul 6, 2026
This was referenced Jul 13, 2026
This was referenced Aug 3, 2026
This was referenced Aug 10, 2026
This was referenced Sep 17, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Locks in the fix for #4751 (the functional fix already shipped in #4764) and lets the issue be closed.
Background
Under
MultiTenantedWithShardedDatabases+UseTenantPartitionedEvents, an asyncCompositeProjectionwas not driven to a non-stale state by the normal daemon catch-up path (StartAllAsync+WaitForNonStaleData/IDocumentStore.WaitForNonStaleProjectionDataAsync) — the composite's member read models stayednullafter catch-up returned, even though the same composite caught up fine viaRebuildProjectionAsyncand in long-running deployed apps.Root cause (shared with #4761, fixed in #4764)
WaitForNonStaleData's "caught up" check could be satisfied by the twoHighWaterMarkrows alone (count >= projectionsCount+all >= initial) without ever requiring the composite's per-tenant projection-progression row — so it reported non-stale before the composite had processed, leaving the member read models empty. #4764 changed the wait to require each registered projection shard's per-tenant progression row to reach its tenant's high-water, which forces it to actually wait for the composite (its member read models commit in the sameProjectionBatchas the composite shard's progression).This PR
Adds the sharded integration regression test: a tenant-partitioned composite under
MultiTenantedWithShardedDatabasesmust materialize both stages via the async daemon (not just viaRebuildProjectionAsync). Verified green on the currentJasperFx 2.13.0master pin — i.e. the merged #4764 fix is sufficient on its own.A separate defensive guard in
JasperFx.Events(ExecutionStage.ExecuteDownstreamAsync, #457 — an invariant assertion that a composite member writes into the sharedProjectionBatch, not a behavior change) is merged to JasperFxmainand will ride the next routine JasperFx version bump; it is not required for this fix.Closes #4751.
🤖 Generated with Claude Code