Expand description
Client Event Log
The goal here is to maintain a single, ordered, append only log of all important client-side events: low or high level, and move as much of coordination between different parts of the system in a natural and decomposed way.
Any event log “follower” can just keep going through all events and react to ones it is interested in (and understands), potentially emitting events of its own, and atomically updating persisted event log position (“cursor”) of events that were already processed.
Structs§
- Event
Kind - Event
LogEntry - Event
LogId - Ordered, contiguous ID space, which is easy for event log followers to track.
- Event
LogId Prefix - Event
LogId Prefix All - Persisted
LogEntry - Struct used for processing log entries after they have been persisted.
- Unorded
Event LogId - A self-allocated ID that is mostly ordered
- Unordered
Event LogEntry - Unordered
Event LogId Prefix All
Constants§
- DB_
KEY_ PREFIX_ EVENT_ LOG - DB_
KEY_ PREFIX_ UNORDERED_ EVENT_ LOG - DB prefixes hardcoded for use of the event log
fedimint-eventlog
was extracted fromfedimint-client
to help include/re-use in other part of the code. But fundamentally its role is to implement event log in the client. There is currently no way to inject the prefixes to use for db records, so we use these constants to keep them in sync. Any other app that will want to store its own even log, will need to use the exact same prefixes, which in practice should not be a problem.
Statics§
- UNORDEREDED_
EVENT_ 🔒LOG_ ID_ COUNTER - An counter that resets on every restart, that guarantees that
UnordedEventLogId
s don’t conflict with each other.
Traits§
Functions§
- handle_
events - run_
event_ log_ ordering_ task - The code that handles new unordered events and rewriters them fully ordered into the final event log.