mirror of
https://github.com/fabro-sh/fabro.git
synced 2026-10-01 02:04:24 +00:00
e2bf05c0f0
The projection folds Petri's public events (replay_since over the run's stored records) and Fabro's platform records into the RunProjection the API serves, row by row as VIEWS.md maps them. The stage key is the execution and firing; the StageId label is node@visit, made unique with the execution when two child invocations would share one. A stage's first_event_seq is the milliseconds from the run's creation to its visit.started, so the view built live equals the view rebuilt from the records whatever order two logs' records were committed in. The projector is the view pass and its wake-up. Records first: an append returns before any view work; a pass reads what is committed, folds the items past the committed positions, and writes the projection document, the ordered stream (one stream_seq per Petri event or platform record, with the item's own identity beside it) and the narrowed runs row in one later transaction. Signals coalesce per run, a lost signal costs only latency, the startup pass folds every run the view trails, and a pass that races a platform record leaves the view alone and runs again. A torn tail holds the view where it stands and reports the run incomplete with the replay's error; inspect_run decides completeness once the run recorded its finish. The tests build the view live for the hello bundle, a command workflow and a two-branch parallel workflow and compare it with the rebuild; drop every wake-up and catch up by a signal and by the startup pass; crash between the record commit and the view transaction and apply only the suffix; restart the projector over child executions; and hold at a torn tail. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| apps | ||
| components | ||
| foundation | ||
| packages/fabro-api-client | ||