- Send a flow's write event inside its transaction, so a clear's event,
sent after its own commit, always comes after it.
- Record a saved request only on a flow that still exists, so a save
that finishes after a clear does not bring the flow back.
- Count the total again from the database a second after new flows,
so a flow both in a page and in the events around it settles to the
right count.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
- Replay live changes over a page of older flows, so a slow flow that
ends while the page loads is not lost from the window.
- Read list_flows' page and total from one snapshot, so a flow written
between them is not counted twice.
- Commit a clear's flow deletion only after its bodies' deletion, so a
failure leaves the flows to clear again rather than orphaned bodies.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The app held every flow in memory and redid all of its work for each new
one: the sidebar mounted every domain and path node (its tree scrolled
inside a container that never bounded it), every tree row looked up its
atoms by scanning every atom the family had made, and the layout, detail
pane and list rows re-rendered per flow. At 3,000 flows each new one cost
about 90 ms of main thread, more than the traffic left time for.
The app now holds a window of the newest 2,000 flows, applies new ones in
batches, and loads older ones in pages from the database on scrolling to
the top, through a new list_flows RPC that pages in SQL. The database
keeps every flow.
Also adds clear_flows: an RPC, POST /flows/clear on the control API, and
a Clear button in the header that Cmd+K opens, confirming first.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
