Parents and children of check-in [bc35cc0c45]
|
2026-08-25
| ||
| 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 | |
| 21:42 |
ops: tie a store call to the request that caused it
The panel could find a slow route and never say why: the render list and the subprocess list were two independent tables, so 'GET /search took 1132ms' and 'zit artifact ran 499 times' could not be connected even when one caused the other. Every request is now tagged at the outermost middleware, and every store call records the tag. Work with no request behind it — ingest rounds, warm passes, the doc indexer — records the empty string, which is itself the useful distinction: store load with nothing to blame is background, and telling the two apart is most of what the subprocess panel is for. Also fixes a silent hole of the same shape as the route-pattern bug: Repo was read with req.PathValue in the outermost middleware, where the router has not set it — the values live on the request the mux passes DOWN. Every render recorded until now carried an empty repo, 61 of 61 rows in the analytics store, which made the numbers unattributable on a fleet where repository size is the dominant cost. Read from the path instead. check-in: bc35cc0c45 user: dmestas tags: ops-drill | |
| 21:27 |
Separate forge truth from derived state: --oltp
--data holds two things that behave nothing alike. Per-repository indexes, built archives and the event store are DERIVED — rebuildable from the stores (0001 5), and therefore private to one node. oltp.db is not: accounts, capability grants, webhooks, praise, mirrors, saved views and CI runs are forge-local truth (0001 8), derivable from nothing. Interleaved in one directory they could not be deployed differently, so two nodes could not have their own fast local index without also having two account databases that disagree. 256KB of the 4.5GB was the whole obstacle to running more than one node. --oltp defaults to <data>/oltp.db, so a single-node deployment is unchanged. Every command that opens the OLTP takes it. Verified: node A creates an account, node B with its own --data and the shared --oltp sees it; node B without the flag reports no accounts, which is the divergence this removes. Both nodes serve at once, each with its own index. check-in: 308751929f user: dmestas tags: trunk | |