From 17b8a95cb077a568751ba7ca91e6fc69097c4c69 Mon Sep 17 00:00:00 2001 From: Meta Vens Date: Sun, 13 Sep 2026 20:44:22 +0200 Subject: [PATCH] Record sequence follow-ups the cache change exposed in CultNet and Mesh The CultNet subscription server and database watches keep latest values from changes that carry no sequence, and the Mesh mirrors' refresh and observe paths race with applied changes. None came from the sequence change; each is named so it is not mistaken for covered. Co-Authored-By: Claude Opus 5 --- docs/cultcache-migration-cut.md | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/docs/cultcache-migration-cut.md b/docs/cultcache-migration-cut.md index 5026851d6..a70ce85f8 100644 --- a/docs/cultcache-migration-cut.md +++ b/docs/cultcache-migration-cut.md @@ -607,6 +607,16 @@ home store, before `_entries` changes. `_lifecycleGate`, and could stall a cache on an interrupted wait; and a non-blocking delivery queue, which kept the same authority in the cache. Cross-process order stays with `StoredAt` and conditional commit. +- Follow-ups outside this migration (found while landing the sequence, CultLib + `4562340`; none introduced by it): `CultNetDatabaseSubscriptionServer.ApplyProjectedChange` + keeps a latest value per record from `CultNetDatabaseChange`, which carries no + sequence (it comes from `OnUpdate`, whose `(previous, current)` signature + cannot, or from database publishes after the cache call), so a stale change + can overwrite a newer one; fixing it means publishing CultNet changes from + `cache.Watch` with `Sequence`. The same holds for `CultNetDatabase.WatchRecord` + and Mesh handles over a database. `RefreshAsync` on the Mesh mirrors writes + its value without a sequence, and `ObserveAsync` reads before subscribing, so + a change between the two is missed. - One key lives in one store: a write or load that would put a key already held from another store throws and changes nothing. - `OnUpdate` fires for loads only, as before the migration; writers publish