Parents and children of check-in [3314daeff6]
|
2026-08-25
| ||
| 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 | |
| 21:46 |
ops: a door from /fleet, and a test that it stays
/fleet/ops linked OUT to /fleet seven times and nothing anywhere linked IN. The page was live, gated, and reachable only by typing the URL. Second surface to ship that way after the notes feed, so it gets a test rather than a promise to remember — both directions, so an admin is never stranded on either. The link goes in the summary strip that already carries the fleet's counts and the error badge, which is where somebody reading health already is. /fleet answers 'are my repositories healthy'; /fleet/ops answers 'is the forge healthy'. check-in: 3314daeff6 user: dmestas tags: ops-drill | |
| 21:45 |
ops: open a route up — which repository, and which store calls
The panel finds a slow route; this says why. Two things the roll-up cannot show. WHICH REPOSITORY. A route pattern folds pikchr and tcl into one line, and repository size is the dominant cost on this fleet — GET /r/{repo} at 420ms could be either, and the two differ by orders of magnitude. WHICH CALLS. Each recent request is listed with the store calls it made, in the order it made them, and what they cost together. A request with no calls listed spent its time somewhere else, which is itself the answer when the store is not to blame. Reads the same rings the panels read, so a request that has aged out simply is not there. That is the honest limit of a snapshot: this answers what a slow request just did, not what happened yesterday. check-in: bb6ec6b896 user: dmestas tags: ops-drill | |