bar chart
Illustrative window growth for a ten-event session with a step of four
Worked example, not a measurement. The window starts at four, grows by four per press, and is clamped to the total.
The new cap was supposed to keep the newest events. It kept the oldest. And the cap was only there because long sessions were crashing my viewer.
The viewer draws an AI coding session as a diagram. Each event is a box, the boxes link up in time order, and a layout library works out where they go. Long sessions broke it. The change that went after it says the library's walk ran out of stack. I don't have a trace, so that's the change's word, not something I watched happen.
One graph for the life of the tab
The layout code used one shared graph for every call. It was made once when the page loaded. Each call added its boxes and links and never took any out, so old views piled up inside it. The change makes a new graph inside each call:
const board = new LayoutBoard(); // now inside the function, not above it
The comment says the pile-up could make the walk loop forever. I'm only half sold. The same change also capped the input, so I can't tell which part did the work. My bet is that size mattered more. Either way, a graph that only lives for one call is the right shape.
Length was the part a fresh graph couldn't touch
A session is basically one long chain of events. If the walk goes one step deeper for each event, a long enough chain runs out of room no matter how clean the graph is. So the change caps the diagram at a couple of hundred events. Short sessions are left alone. Longer ones show a banner with how many events are visible out of the total, plus a button that loads another batch, never more than what's left.
And the cap took the wrong end
The first version sorted oldest first and kept the front of the list. For a coding session that's the worst half. The start is mostly reading and planning; the end is where it worked or didn't. It threw no error and drew a normal-looking diagram, so only a reader could spot it. A review caught it before merge, and now the window starts at the newest events and the button reaches back in time.
The tracker plumbing
Render errors now go to my error tracker with a note saying which component broke. The tracker's key was also renamed so the browser can read it. I suspect browser reporting did nothing before that, but I haven't checked.
The button still has no ceiling, so enough clicks bring the whole chain back. Neither commit added a test for which end of the list the cap keeps, which is exactly the mistake that already happened once.
The chart below is a made-up ten-event example, not a measurement, of how that window grows with each press until it hits the total.