Bump JasperFx.Events from 2.37.0 to 2.39.5

[dependabot]

Updated JasperFx.Events from 2.37.0 to 2.39.5.

Release notes

Sourced from JasperFx.Events's releases.

2.39.5

What's Changed

• Compliance wave 5 part 1: explorer, archiving and FetchLatest suites (2.39.4) by @​jeremydmiller in Compliance wave 5 part 1: explorer, archiving and FetchLatest suites (2.39.4) JasperFx/jasperfx#633
• fix: composed block chains (PushUpstream) report the whole chain's Count and drain all the way down by @​jeremydmiller in fix: composed block chains (PushUpstream) report the whole chain's Count and drain all the way down JasperFx/jasperfx#632

Full Changelog: JasperFx/jasperfx@V2.39.3...V2.39.5

2.39.3

What's Changed

• Extended progression batches amortize the connection, not the transaction (2.39.2) by @​jeremydmiller in Extended progression batches amortize the connection, not the transaction (2.39.2) JasperFx/jasperfx#630
• ExtendedProgressionWriter: don't lose the first status transition, and say when a duplicate writer attaches by @​jeremydmiller in ExtendedProgressionWriter: don't lose the first status transition, and say when a duplicate writer attaches JasperFx/jasperfx#631

Full Changelog: JasperFx/jasperfx@V2.39.1...V2.39.3

2.39.1

A single fix on top of 2.39.0.

EventProjection teardown (#​626)

JasperFxEventProjectionBase's constructor never touched Options, so an EventProjection registered no teardown targets — Options.CleanUps and Options.StorageTypes stayed empty unless the author hand-called Options.DeleteViewTypeOnTeardown<T>(). Aggregation projections have always registered their single TDoc, and nothing in the API surface signalled the difference.

Everything that derives "what does this projection own" from those lists silently did nothing for event projections: a rebuild deleted the progression row and then re-projected into a table still holding the previous run's documents, per-tenant progression deletion left the documents behind, and the ProjectionScenario harness wipe never wiped after an event projection.

Published types are now registered as teardown targets in AssembleAndAssertValidity() rather than the constructor — the source generator emits its RegisterPublishedType calls into the subclass constructor, which runs after the base one, so only assembly time sees the complete set. Registration is idempotent.

Behavior change

Rebuilding an event projection now truncates the document types it publishes. That is the point of the fix, but if a projection writes into storage it doesn't own — an append-only audit table, or documents another projection owns — set the new opt-out:

public class MyProjection : EventProjection
{
    public MyProjection()
    {
        DeletePublishedTypesOnTeardown = false;
    }
}

It is all-or-nothing: turn it off and call Options.DeleteViewTypeOnTeardown<T>() for the types you do want wiped.

Because DeleteViewTypeOnTeardown writes to both CleanUps and StorageTypes, the ProjectionScenario test-harness wipe also starts working after event projections. Desirable, and now deliberate rather than incidental.

What's Changed

• fix: register an EventProjection's published types as teardown targets (#​626) by @​jeremydmiller in Register an EventProjection's published types as teardown targets (#626) JasperFx/jasperfx#629

Full Changelog: JasperFx/jasperfx@V2.39.0...V2.39.1

2.39.0

Projection lag, per-tenant high-water parsing, and a large cut in the async daemon's idle database traffic.

Highlights

A supported per-tenant projection lag read (#​619, #​627). "How far behind is projection X, at its current version, for tenant T on this database?" had no supported answer, so the correlation had been reinvented three times — the daemon's blue/green side-effect gate, Marten's WaitForNonStaleDataAsync, and application code in the field — each rediscovering the same traps. ProjectionLag + ProjectionLagCalculator + IEventDatabase.FetchProjectionLagAsync / IEventStore<,>.FetchProjectionLagAsync now express it once, anchored on registered sources at their current version, over the single AllProjectionProgress round trip that already exists. No new SQL, and every store gets it through a default interface implementation. A registered cell with no row reads as fully behind, not caught up.

Per-tenant HighWaterMark:{tenant} rows round-trip through ShardName (#​618, #​623). ShardName.TryParse("HighWaterMark:acme", ...) used to return true and a wrong answer — the tenant id in the shard-key slot, TenantId null, and an Identity that didn't match the input. Those rows are real and persisted (Marten writes one per tenant on every vectorized high-water poll), so any consumer grouping progression rows by tenant silently attributed every tenant's mark to the store-global one. ShardName.HighWaterMarkFor(tenantId) and ShardName.IsHighWaterMark are the supported way to compose and recognize them.

Only a daemon that actually runs agents writes extended progression telemetry (#​621, #​625). The ShardStateTracker is per-database and shared, and every JasperFxAsyncDaemon subscribed an ExtendedProgressionWriter to it in the constructor — including daemons built ad hoc purely to read state, which is a documented thing to do. N daemons for one database meant N writers on one publication stream, each renting a connection and issuing the same UPDATE against the same rows. The subscription is now armed on the start path and released on stop; an unstarted daemon writes nothing at all.

The periodic per-shard heartbeat is off by default (#​622, #​628). It cost one pooled connection and one transaction per database per node every 5 seconds — ~37 connection acquisitions/sec/node on a 512-shard-database deployment — and an audit across JasperFx, Marten and CritterWatch found nothing that reads the persisted value. Agent status transitions are still written, which is what the extended columns are actually for. The cadence is now reachable from application code for the first time via DaemonSettings.ExtendedProgressionHeartbeatInterval; a positive value restores the old behavior as a compatibility hatch.

Upgrade notes

• Per-tenant high-water ShardNames are now distinct values where they previously all compared equal to the store-global mark. That collapse was the bug; nothing in JasperFx constructed such a name.
• TryParse now rejects HighWaterMark-prefixed strings other than the bare constant and HighWaterMark:{tenant}, instead of forcing them into the generic grammar.
• If you depend on the persisted 5-second heartbeat, set DaemonSettings.ExtendedProgressionHeartbeatInterval. Nothing in the Critter Stack reads it today.

What's Changed

• fix: round-trip per-tenant HighWaterMark progression rows through ShardName (#​618) by @​jeremydmiller in Round-trip per-tenant HighWaterMark progression rows through ShardName (#618) JasperFx/jasperfx#623
• feat: supported per-tenant projection lag read (#​619) by @​jeremydmiller in Supported per-tenant projection lag read (#619) JasperFx/jasperfx#627
• fix: only a daemon that actually runs agents writes extended progression (#​621) by @​jeremydmiller in Only a daemon that actually runs agents writes extended progression (#621) JasperFx/jasperfx#625
• feat: stop writing a periodic per-shard heartbeat nobody reads (#​622) by @​jeremydmiller in Stop writing a periodic per-shard heartbeat nobody reads (#622) JasperFx/jasperfx#628

Full Changelog: JasperFx/jasperfx@V2.38.0...V2.39.0

2.38.0

What's Changed

• fix: never adopt a test runner as the application assembly (#​600) by @​jeremydmiller in fix: never adopt a test runner as the application assembly (#600) JasperFx/jasperfx#602
• fix: make DatabaseId's escaping survive a System.Uri round trip (#​599) by @​jeremydmiller in fix: make DatabaseId's escaping survive a System.Uri round trip (#599) JasperFx/jasperfx#603
• fix: attribute registration to the app, not the extension that registered for it (#​601) by @​jeremydmiller in fix: attribute registration to the app, not the extension that registered for it (#601) JasperFx/jasperfx#606
• fix: CallingAssembly.Find could adopt a test runner too (#​600) by @​jeremydmiller in fix: CallingAssembly.Find could adopt a test runner too (#600) JasperFx/jasperfx#605
• Add JasperFx.Events.ComplianceTests source-only package (2.37.1) by @​jeremydmiller in Add JasperFx.Events.ComplianceTests source-only package (2.37.1) JasperFx/jasperfx#607
• Compliance wave 2: EventProjection, auto-discovery and rebuild-cap suites (2.37.2) by @​jeremydmiller in Compliance wave 2: EventProjection, auto-discovery and rebuild-cap suites (2.37.2) JasperFx/jasperfx#608
• Fix the race in SideEffectGateTimeoutTests.a_timeout_that_did_not_reach_the_prior_mark_pauses_the_shard by @​jeremydmiller in Fix the race in SideEffectGateTimeoutTests.a_timeout_that_did_not_reach_the_prior_mark_pauses_the_shard JasperFx/jasperfx#609
• Discover EventProjection published types semantically, not syntactically by @​jeremydmiller in Discover EventProjection published types semantically, not syntactically JasperFx/jasperfx#611
• Fail the publish when the line version is already on nuget.org by @​jeremydmiller in Fail the publish when the line version is already on nuget.org JasperFx/jasperfx#614
• Compliance wave 3: activity correlation and string stream identity suites by @​jeremydmiller in Compliance wave 3: activity correlation and string stream identity suites JasperFx/jasperfx#613
• Lift the ProjectionScenario test harness into JasperFx.Events by @​jeremydmiller in Lift the ProjectionScenario test harness into JasperFx.Events JasperFx/jasperfx#616
• Move the blue/green side-effect gate warm-up out of the agent start path (#​598, #​610) by @​jeremydmiller in Move the blue/green side-effect gate warm-up out of the agent start path (#598, #610) JasperFx/jasperfx#615
• Make container-scoped projections usable by live aggregation and validate them by @​jeremydmiller in Make container-scoped projections usable by live aggregation and validate them JasperFx/jasperfx#617

Full Changelog: JasperFx/jasperfx@V2.37.0...V2.38.0

Commits viewable in compare view.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Looks like JasperFx.Events is no longer updatable, so this is no longer needed.