Only a daemon that actually runs agents writes extended progression (#621)

[jeremydmiller]

Closes #621.

The problem

Tracker is per-database and shared. Every JasperFxAsyncDaemon subscribed an ExtendedProgressionWriter to it in the constructor, unconditionally — so N daemons for one database meant N writers on one publication stream, each renting its own connection and issuing the same UPDATE ... FROM unnest(...) against the same rows.

That includes daemons built purely to read. BuildProjectionDaemonAsync is new ProjectionDaemon(...) per call with no caching, and nothing in its signature suggests the returned object owns a background write loop against the database. CritterWatch's EventProgressionPoller did exactly this, once per node-owned database every 15 seconds, without disposing — the likely mechanism behind marten#5167, where the blocker and the blocked statement in pg_stat_activity were both the heartbeat UPDATE, same database, same node, zero agent churn.

The fix

Option 2 from the issue — move the subscription off the constructor — funnelled at the points where the daemon actually takes ownership of a shard rather than at one public method, so it also covers "a caller deliberately starts a second daemon":

• armExtendedProgressionWriter() builds and subscribes the writer, called from StartHighWaterDetectionAsync, tryStartAgentAsync (the funnel every continuous start path goes through), rebuildAgent and PrepareForRebuildsAsync. Idempotent — repeated starts can't stack a second subscription on the shared tracker.
• StopAllAsync unsubscribes and drains exactly as before, but no longer resubscribes at the end; the next start re-arms a fresh writer. Daemon shutdown doesn't drain extended-progression writer or barrier the batch-write throttle → late telemetry clobbers rows + ObjectDisposedException on SemaphoreSlim #557's "resume after a rebuild keeps persisting extended progression" guarantee is preserved, just relocated.
• Dispose() handles the never-armed case.

An unstarted daemon now creates no subscription, no Block, and no connection — the writer object isn't even built.

Tests

src/EventTests/Daemon/ExtendedProgressionSubscriptionLifecycleTests.cs — 8 tests over a shared tracker and a write-counting IEventDatabase: an unstarted daemon writes nothing, five unstarted daemons still write nothing, a started daemon does write, one owner + three ad-hoc readers produce exactly one write per publication (not four), starting twice doesn't double-write, a stopped daemon stops, a restarted daemon resumes, and disposing a never-started daemon is clean. Full EventTests suite passes (686).

Not addressed here

The two related items in the issue belong to the cost model in #622 and are handled there: HeartbeatWriteInterval having no configuration path, and _lastFlush starting at MinValue so a fresh writer flushes on its first publication. The latter is reasonable now that a writer only exists on a genuine daemon start.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Fuk1GybEEmohFmboJuM4Po