Per-party document sync cadence (honour PartyReadModel.syncFrequency) #49

New issue

Closed

opened 2026-07-04 12:11:43 +00:00 by momsse · 0 comments

momsse commented

2026-07-04 12:11:43 +00:00

Owner

Migré depuis viziertronic/octant#108 — ouvert le 2026-06-27 par @momsse.

Follow-up from #40 (epic #42).

SynchronizePartyDocumentsDaemonLayer currently syncs every party at one global partyDocumentsSyncInterval, ignoring each party's syncFrequency (a Duration already modelled on the Party aggregate / read model). The plan calls for "cron selon la fréquence du party".

Honouring per-party cadence needs a per-party "last synced at" timestamp to compare against syncFrequency — which the Party aggregate does not model today (unlike Banking's lastTransactionCheckAt).

Work

Add a Party-side last documents sync at (command/event/state + read model), set when SynchronizePartyDocuments completes.
In the daemon, run the daemon at a base cadence and sync a party only when now - lastSyncedAt >= party.syncFrequency.

Until then the global interval is the pragmatic behaviour.

> _Migré depuis [viziertronic/octant#108](https://github.com/viziertronic/octant/issues/108) — ouvert le 2026-06-27 par @momsse._ Follow-up from #40 (epic #42). `SynchronizePartyDocumentsDaemonLayer` currently syncs every party at one global `partyDocumentsSyncInterval`, ignoring each party's `syncFrequency` (a `Duration` already modelled on the Party aggregate / read model). The plan calls for "cron selon la fréquence du party". Honouring per-party cadence needs a per-party "last synced at" timestamp to compare against `syncFrequency` — which the Party aggregate does **not** model today (unlike Banking's `lastTransactionCheckAt`). ## Work - Add a Party-side `last documents sync at` (command/event/state + read model), set when `SynchronizePartyDocuments` completes. - In the daemon, run the daemon at a base cadence and sync a party only when `now - lastSyncedAt >= party.syncFrequency`. Until then the global interval is the pragmatic behaviour.

momsse closed this issue

2026-07-04 12:11:44 +00:00