diff --git a/Directory.Build.props b/Directory.Build.props index b08edbc9d6..60d1192341 100644 --- a/Directory.Build.props +++ b/Directory.Build.props @@ -1,7 +1,7 @@ - 9.22.3 + 9.22.4 13.0 Jeremy D. Miller;Babu Annamalai;Jaedyn Tonee https://martendb.io/logo.png diff --git a/Directory.Packages.props b/Directory.Packages.props index acdf451128..0487d31260 100644 --- a/Directory.Packages.props +++ b/Directory.Packages.props @@ -202,21 +202,32 @@ slow projection batch on one row stalled every other shard's telemetry on that database (Marten's side of this is #5186, which does not depend on this bump). The ordering closes the cross-writer deadlock hazard — the tracker is per-database and shared, and - BuildProjectionDaemonAsync is not cached, so two writers can race over the same rows. --> - - + BuildProjectionDaemonAsync is not cached, so two writers can race over the same rows. + JasperFx 2.39.3: two extended-progression fixes Marten consumes directly. + jasperfx#631 — a status transition published while the shard has NO progression row to + decorate landed nowhere, because every store's extended-progression write is update-only. + That is every fresh shard's Started: the agent starts before its first batch commits. With + the periodic beat off by default (jasperfx#622) there was no later write to correct it, so + agent_status/heartbeat stayed NULL for the entire life of a healthy agent. Such a shard is + now remembered and written again on the first publication carrying a committed sequence. + jasperfx#630 follow-up — a duplicate ExtendedProgressionWriter on one database now logs a + warning. It used to announce itself as lock contention; one-row-per-transaction writes made + it harmless to correctness and therefore silent, while still meaning two daemons are + started for one database. Reported, never refused: the duplicate is the symptom. --> + + - - + + all runtime; build; native; contentfiles; analyzers; buildtransitive - +