mirror of
https://github.com/fabro-sh/fabro.git
synced 2026-10-01 02:04:24 +00:00
1ed30db1d6
Each projector pass replayed the run whole through `replay_since` to rebuild the engine and invocation state the derivation needs, so a pass cost the run's length. The projector now keeps, per live run and behind the run's pass lock, Petri's `RunReplay` and the view as the last committed pass left it (`projector/cache.rs`), and a pass advances the replay over the records past the ones it consumed: it reads and folds only the new records. The SQLite store answers `read_from` with `seq >= ?`, and the signalling store forwards it. The rules hold as before. Records first: the cache moves only after the view transaction commits, and a pass that commits nothing (a platform record landed under it, a fault before the transaction) keeps the events it derived as pending for the next pass. The cache is never checkpointed and never a source of facts: it is dropped when the run records its finish, after ten idle minutes, when the stored view moves under it, when the run is deleted, and with the process; the first pass after that rebuilds it by a full replay, filtered to the held positions. A torn tail fails the advance, which leaves the replay where it stood, so the view holds and the pass is retried. `PassReport::replayed_records` says how many records a pass fed through the derivation. Two projection tests: the records of a parallel run land in batches and every pass replays at most its batch, with the finished run's cache dropped; a restart and the idle period drop the cache and the next pass replays the run so far once, then only its new records, and the view equals the rebuild throughout. `test_support` exposes whether a cache is held and the idle sweep. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| apps | ||
| components | ||
| foundation | ||
| packages/fabro-api-client | ||