Obeya's stalls.log and app.log on the owner's Mac, from 29 October around 20:00 to 2 November 08:00 (CET). Follow-up to the fix for slow look-ups of archived cards.
All three groups below were fixed on 31 October at 12:47 (demo frames clean-up, board changes, git calls on agent starts and landings). In the 43 hours since then, Obeya logged:
| What | Stalls | Length | Where the time went | Proposed card |
|---|---|---|---|---|
| Looking up archived cards for sharing 31 Oct, 20:08, as a landing shared its demo |
1 | 0.5 s | The same path as the original problem, now far shorter: each look-up of one archived card still loads and prepares every prototype of the canvas, once for each of about 200 shared cards | Nachschlagen archivierter Karten lädt alle Prototypen jedes Mal neu |
| A page on this machine 2 Nov, 02:25 and 05:01, canvas Obeya |
2 | 0.7–0.8 s | The browser does not say where the time went; both at night | none |
No stall of the demo frames clean-up, the board snapshot or the git calls has come back.
Before the fix, sharing looked up every shared card in the archive and held the server up to 10 s. In both checks no stall pointed there, although many cards landed and were shared in that time. One stall on 30 October touched an archived-card look-up for 7% of its 0.7 s; most of its time went elsewhere (see group 2 below).
From the app's start on 29 October 20:32 until 30 October 09:37, the Mac app's window (canvas Super 59) reported a stall of about 0.9 s nearly every second: over 40,000 entries, all night long. The page was not frozen (its process idled at under 1% CPU): WebKit ran the page's watch timer only once a second while still calling the page visible. The flood made stalls.log start afresh every two hours, so real server stalls of the afternoon of 29 October were lost.
Fixed on 30 October at 12:02 (A page held back by the browser no longer reports stalls; repeated ones are counted). Since then: one page stall in 21 hours (0.6 s, canvas Obeya).
Server stalls from 30 October 09:00 to 31 October 09:00 (CET). Eight of them fell in the half hour around noon on 30 October, when many cards landed one after the other.
| Group | Stalls | Length | Where the time went | Proposed card |
|---|---|---|---|---|
| 1. Demo frames clean-up at start, then every six hours |
5 | 0.5–0.7 s | Walking the demo folder (about 1,000 entries) with synchronous file calls (lstatSync, readdirSync in demo-space.ts) |
Aufräumen alter Demo-Frames ohne Server-Hänger |
| 2. Board snapshot on every change during bursts of activity |
4 | 0.5–0.7 s | The Koordinator rebuilds the whole board snapshot on every change only to find projects being arranged; the owner's language file is read from disk at every translation call | Server-Hänger durch Board-Snapshot bei jeder Änderung |
| 3. Synchronous git calls during bursts of landings |
3 | 0.7–1.1 s | Synchronous git when an agent starts (is the repository's Claude configuration trusted?) and when a repository is read again after main moved, plus many git processes started at once |
Synchrone git-Aufrufe beim Agentenstart und Neulesen der Repositories |
Group 1 counts one stall from 29 October, 20:32, before the window above. None of the stalls are long enough to notice as more than a brief hitch; the longest was 1.1 s.
stalls.log, and app.log starts afresh with each start of the app.