anagrapheus.timeline.recording¶
anagrapheus.timeline.recording
¶
A recorded run on disk, in the log's own serialization.
A recorded pin ledger is a fixture, but it is also the log format: does it use the same serialization, or a test-facing one? Until this module the question was open in practice as well as on paper. Every replay in the repository was built from a live store in the same test that recorded it, so the strongest form of the replay claim — a run recorded earlier, by another process, loaded from a file — had never been exercised.
Same serialization. Every event line is a :class:~anagrapheus.timeline.StoredEvent
exactly as the store holds it. The reason is not tidiness: an event in the log's own
format is upcast as it is read into a replay, like any other —
:meth:~anagrapheus.timeline.ReplayPins.from_events with upcasts= — so a recording
made today survives a future change to the event it carries. A test-facing format would
need a migration story of its own, and would get one only after the first fixture had
silently stopped loading.
One header line, first, saying what produced the events. For a pin corpus that matters more than it looks: a pin key includes the model's id, so the same story recorded through a different provider route is a different corpus, and a replay against the wrong one misses on every draw. The header is where a reader finds out which.
Canonical JSON throughout, sorted keys and no whitespace, so re-recording an unchanged run changes only what genuinely differs — ids, timestamps, the responses — and a recording's diff is reviewable rather than reshuffled.
RecordingError
¶
Bases: TimelineError
A file that is not a recording this version of the library can read.
Recording
¶
Bases: NamedTuple
A recording read back: what produced it, and the events.
pin_events
¶
The pin corpus: only the events a replay reads.
A whole log is mostly what the run did — minted beliefs, established entities — and none of it can be replayed into a fresh store, whose ids will all differ. What makes a run reproducible is the pins, so that is what a recording usually keeps.
Source code in src/anagrapheus/timeline/recording.py
write_recording
¶
Write events to path, after one header line. Returns how many were written.
The header must not claim the format key itself: that key is how a reader tells a recording from any other JSON-lines file, and letting a caller overwrite it would make a file that announces one format and holds another.
Source code in src/anagrapheus/timeline/recording.py
read_recording
¶
Read a recording back. Refuses anything that does not say it is one.
Raises rather than guessing on a missing or unknown format marker. A JSON-lines file of events with no header could be loaded — and then the one thing a pin corpus most needs to say, which route recorded it, would be missing without anyone noticing.
Events come back exactly as stored: not upcast. Pass them to
:meth:~anagrapheus.timeline.ReplayPins.from_events with upcasts= so they are
brought to the current schema on the way in, as anything read from a log is.