{"session": "d934c0db-2307-441f-978e-6fba4b5950f9", "env": "main", "command": "journal todo done 4274 --how \"Fixed in 0ee3a6feb: a run holds a lock for as long as it lives, so the lock is what says whether it is alive, and the stamp alone never did. Checks.forget_dead_runs clears the stamp of any check whose lock is free, called from the clock sweep that already looks for due checks; a run still holding its lock is left alone. The regression is in the checks test that already covers a run: stamp a run with its lock free and the check reads as not running; stamp one with the lock held and the stamp stays. 10 of 10 checks tests pass.\" 2>&1 | tail -1; journal comment create \"A second sample, same shape: the first read after a write pays\" --brief \"transportklok on 2.270.0: POST /api/run (ticket show) took 254ms with 124ms of working time, 47ms on locks and 144ms after answering, at load 10.4 - and again it was the first ticket show straight after a ticket create and a ticket start. Two independent samples now, both the first read after a write, both over budget on working time, where a repeated read is 20 to 30ms.\n\nFrom the same session: command ticket start took 87ms with 0ms of working time, which is the machine alone and not this.\" --set about=todo:4288 2>&1 | tail -1", "parts": ["journal todo done 4274 --how \"Fixed in 0ee3a6feb: a run holds a lock for as long as it lives, so the lock is what says whether it is alive, and the stamp alone never did. Checks.forget_dead_runs clears the stamp of any check whose lock is free, called from the clock sweep that already looks for due checks; a run still holding its lock is left alone. The regression is in the checks test that already covers a run: stamp a run with its lock free and the check reads as not running; stamp one with the lock held and the stamp stays. 10 of 10 checks tests pass.\" 2>&1 | tail -1", "journal comment create \"A second sample, same shape: the first read after a write pays\" --brief \"transportklok on 2.270.0: POST /api/run (ticket show) took 254ms with 124ms of working time, 47ms on locks and 144ms after answering, at load 10.4 - and again it was the first ticket show straight after a ticket create and a ticket start. Two independent samples now, both the first read after a write, both over budget on working time, where a repeated read is 20 to 30ms.\n\nFrom the same session: command ticket start took 87ms with 0ms of working time, which is the machine alone and not this.\" --set about=todo:4288 2>&1 | tail -1"]}