LiveProjection receives events automatically after catch_up() — likely an observer/callback registered on the store's append pathDate: 2026-05-29
Time: 08:00
The observations cut off at line 200, and LiveProjection starts at line 219 — so we're missing the actual class. But we have enough from the surrounding code and the test to reconstruct exactly how it works.
event-sourcing-store/eventstore.py:LiveProjection — Read the full class body to confirm whether subscription happens in init or catchup(), and whether it guards against double-subscriptionevent-sourcing-store/eventstore.py:appendbatch — Batch notification happens *after* all events are stored, unlike append which notifies per-event — explore whether this ordering difference matters for projectionscatch-up-subscription-gap — Consider whether there's a race between catch_up() finishing and the subscriber being registered — if an event is appended between those two steps, it could be missedevent-sourcing-store/test_verify.py — Additional test coverage for LiveProjection behavior, including edge cases around catch-up timingprojection-snapshot-interaction — How snapshots interact with LiveProjection — does a live projection ever snapshot, and can it restore from one while maintaining its subscription?live-projection-uses-subscriber-list — LiveProjection receives automatic updates by registering a callback in EventStore.subscribers, which is invoked synchronously inside append() and appendbatch()subscriber-dispatch-is-synchronous — Event subscriber notification blocks the append() caller — projections update before the append call returns to the writerbatch-notifies-after-all-stored — append_batch() stores all events first, then notifies subscribers of each event, ensuring subscribers see a consistent multi-event statecatch-up-then-subscribe — LiveProjection implements the catch-up subscription pattern: replay historical events via read_all(), then switch to push-based updates for future events, bridging the pull/push boundary at a known position