feat(mongoreactive): add journal event persistence - #955
Conversation
davidfrigolet
left a comment
There was a problem hiding this comment.
A few points from reviewing against the merged sync sibling (flamingock-mongodb-sync-auditstore). None block, but 1 and 2 are easy removals.
| *.db-wal | ||
| *.db-shm | ||
| # Local Pi runtime state | ||
| .atl/ |
There was a problem hiding this comment.
This one is intentional. It ignores a directory generated by my local development environment that should never be tracked.
I agree it is unrelated to journal events, but I do not think it warrants a separate PR for a single repository-hygiene entry. It does not affect the implementation or runtime behavior.
| persistence = new MongoDBReactiveAuditPersistence( | ||
| public AuditPersistenceFactory<CommunityAuditPersistence> getPersistenceFactory() { | ||
| return stageId -> { | ||
| auditRepository.initialize(autoCreate); |
There was a problem hiding this comment.
auditRepository.initialize(autoCreate) (and journalEventStore.initialize below) run here, then again in stagePersistence.initialize(runnerId) -> doInitialize(). Both are guarded so it's harmless, but the sync sibling only initializes inside persistence.doInitialize(). Consolidate to one site. Keep the journal-store init before forStream(stageId) though — the manual-schema validation test depends on that ordering.
There was a problem hiding this comment.
I looked into this properly. We cannot just move these calls into doInitialize() with the current flow: forStream(stageId) immediately reads the last persisted journal event, but doInitialize() runs afterwards. That would make the sequencer read the journal before its schema is
created or validated, especially breaking the intended autoCreate=false validation boundary.
The duplicate calls are idempotent and currently preserve the required order:
audit initialization → journal initialization/validation → sequencer creation
I agree the lifecycle is not clean. The right solution is a cross-audit-store refactor: persistence should receive the stage ID and sequencer factory, initialize the repositories, and then create the sequencer itself.
That refactor should be applied consistently across the audit stores, not only MongoDB Reactive. It is therefore better handled separately from this PR, rather than introducing a broader lifecycle-contract change here.
No description provided.