| Comment: | Accepted. The link was in the DAG the whole time, and the history is finally being read. |
|---|---|
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA3-256: |
23cec0f0fdfc1eab0c572889c5c19c94 |
| User & Date: | dmestas on 2026-08-26 11:24:35.285 |
| Other Links: | manifest | tags |
|
2026-08-26
| ||
| 12:43 |
Timeline: a revision signal, not rendered rows
The stream carried the filter it was opened with, so every later tick repainted the reader's page with a view they had left. That is not a bug that gets fixed once — it shipped, was fixed this morning, and would come back the next time a default moved, because the shape makes it possible. The fleet page was rebuilt around a revision number for this reason. The timeline now follows: the signal says THAT the repository changed, the client re-requests the listing and sends its own controls with it. Nothing can capture a filter and outlive it. A fragment is delivered as SSE but is a render, so it is marked and still measured — otherwise the refresh path would have been the one route the ops panel could not see. closed check-in: 0f1c202c58 user: dmestas tags: tl-rev | |
| 12:41 |
A settled landing diffs against its fork, not the moving tip
An accepted landing showed an empty Changes section. Not an error — the right answer to a question nobody was asking. While a landing is OPEN the useful base is the target's current tip: what would merging this change now. ForkPoint's comment says as much and calls the distinction deliberate. But once the record is SETTLED the branch is already contained in the target, so that question has a degenerate answer, and the only reading left is historical: what did this branch do. That is the fork point. Base is chosen by state now. On the record that prompted this, the diff goes from 0 files to 12. Second defect in the same block: the else branch says it exists so an empty Changes section never reads as 'no changes', but it only fires when the invoke FAILS. A call that succeeded and found nothing fell through to the success path and rendered exactly that blank. It now says so, naming both check-ins. check-in: 469dbab422 user: dmestas tags: trunk | |
| 11:24 | Accepted. The link was in the DAG the whole time, and the history is finally being read. check-in: 23cec0f0fd user: dmestas tags: trunk | |
| 11:24 |
ops: read the history back — a route across days
The store recorded renders and nothing read them. The panels are one process's memory, so the page could say how fast a route is now and never whether it is worse than it was — which is the question after a deploy. The drilldown gains a per-day table from the store: p50, p95, max. Nearest-rank percentiles, matching how the snapshot computes them, so two numbers on one page both called p95 agree. Empty for no traffic and empty for history-off are different answers and the page gives the right one. closed check-in: a0fa952495 user: dmestas tags: landing-merge | |
| 10:05 | Accepted. A decision record and a discussion thread are different things, and the timeline now says which is which. check-in: 349027e507 user: dmestas tags: trunk | |