From 451e7914aebbaca0b1995d19db2f9b07d81e40c6 Mon Sep 17 00:00:00 2001 From: "Jeremy D. Miller" Date: Tue, 4 Aug 2026 13:03:44 -0500 Subject: [PATCH] Adopt JasperFx 2.39.3 and release 9.22.4 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 describes every fresh shard's Started: the agent starts before its first batch commits. With the periodic beat off by default since jasperfx#622 there was no later write to correct it, so agent_status and heartbeat stayed NULL for the entire life of a healthy agent. The shard is now remembered and written again on the first publication carrying a committed sequence, which is proof the row exists. The jasperfx#630 follow-up: a duplicate ExtendedProgressionWriter on one database now logs a warning. It used to announce itself as lock contention -- two writers issuing multi-row UPDATEs over the same rows in plan-dependent order is a deadlock hazard. The one-row-per-transaction rewrite in #5186 made a duplicate harmless to correctness and therefore SILENT, while it still means two projection daemons are started for one database. Reported and not refused: the duplicate writer is the symptom, not the bug. Version bumped to 9.22.4 for the release. DaemonTests 301/301 green on net9.0. Co-Authored-By: Claude Opus 5 (1M context) Claude-Session: https://claude.ai/code/session_017CTtw2kVRSZKp1p5RTxgAy --- Directory.Build.props | 2 +- Directory.Packages.props | 23 +++++++++++++++++------ 2 files changed, 18 insertions(+), 7 deletions(-) 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 - +