| Comment: | Accepted. It can now say which repo and which calls — which is the difference between finding a slow route and fixing one. |
|---|---|
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA3-256: |
7059271e59f94618ec827f63ab98ddf4 |
| User & Date: | dmestas on 2026-08-25 21:53:53.488 |
| Other Links: | manifest | tags |
|
2026-08-25
| ||
| 22:02 |
Timeline stream: keep the reader's filter
The check-ins default lived only in the page handler, so a reader on the default timeline had an empty query string — and the live stream opened with it asked for no filter at all. The first tick after a landing replaced their check-ins with everything. Both the page and the stream now resolve through timelineQuery. closed check-in: 550f9601a2 user: dmestas tags: tl-filter | |
| 21:58 |
Remove g1.json, g2.html, g3.json — committed debugging scratch
Three files written in the same minute on 15 Aug and committed by accident. g1.json is a wiki API response for a page titled 'evil/traversal', g2.html the rendered edit page for it, g3.json a failed call that returned 'no such endpoint'. curl -o output, named g1 through g3, left in the repository root where they read as though they belong to the project. Nothing references them: no Go file, no Makefile, no Dockerfile. They shipped with every clone and told a reader nothing except that someone was probing path traversal in wiki page names that evening. check-in: 2946cb4429 user: dmestas tags: trunk | |
| 21:53 | Accepted. It can now say which repo and which calls — which is the difference between finding a slow route and fixing one. check-in: 7059271e59 user: dmestas tags: trunk | |
| 21:53 | Accepted. A connection is not a render. check-in: 242e2d8c1c user: dmestas tags: trunk | |
| 21:49 |
ops: record which repository a render was for
Repo was read with req.PathValue in the outermost middleware, where the router has not set it — path values live on the request the mux passes DOWN, a copy that middleware never sees. Same shape as the route-pattern bug, and it went unnoticed longer because an empty string looks like 'no repository' rather than like a failure. Every render recorded until now carried an empty repo: 61 of 61 rows in the analytics store, on a fleet where repository size is the dominant cost of almost everything. The drilldown's by-repository table showed a single '(none)' row, which is what surfaced it. Read from the path instead, unescaping as the router would. closed check-in: 059fe0bdde user: dmestas tags: ops-drill | |