---
{
  "n": 73,
  "title": "Follow-up email to Johannes Jan Prins",
  "abstract": "",
  "refs": [
    "message:15010",
    "todo:2582"
  ],
  "seen": [
    "agent",
    "system",
    "user"
  ],
  "data": {
    "written": true,
    "environment": "main",
    "revisions": 1,
    "open_until": 1791141870.922891,
    "buttons": [
      {
        "label": "Send it as written",
        "say": "The email to Johannes is good, I will send it",
        "choice": "answer"
      },
      {
        "label": "Change it first",
        "say": "I want changes to the email to Johannes first",
        "choice": "answer"
      }
    ],
    "pressed": [
      "Send it as written"
    ]
  },
  "created": 1791140070.874521,
  "updated": 1791140400.506957,
  "deleted": 0.0,
  "completed": 0.0,
  "outcome": "",
  "type": "doc"
}
---


## Concept
**Onderwerp:** Re: viewer onbruikbaar en serve.py op 100% CPU

Hoi Johannes,

Dank voor je heldere melding, en vooral voor de sample en de bestandsgroottes: daarmee was de oorzaak snel te vinden.

**Wat er gebeurde.** De journal houdt per agent-transcript bij wat hij er al uit heeft gelezen, zodat hij bij elke hook alleen het nieuwe stuk hoeft te lezen. Die administratie was gekoppeld aan het versienummer. Na elke update, ook een automatische, begon de server daarom elk transcript weer van voren af aan te lezen. Met transcripts van 43 MB en 10 MB is dat minutenlang JSON parsen op één core. In die tijd beantwoordde de server bijna niets: pagina's liepen in een timeout, de viewer gaf het op (dat zijn die honderden BrokenPipeErrors in viewer.log) en de hooks kregen geen antwoord. Daarna was alles weer bijgelezen, en daarom werd het na een paar minuten vanzelf weer snel.

Je geplakte stylesheet was het niet. We hebben een regel van 338 KB nagebootst: die kost bij het tonen eenmalig ongeveer een tiende seconde en daarna niets meer.

**Wat er in 2.249.2 verandert:**

- Na een update leest de journal transcripts niet meer opnieuw van voren af aan. Wat hij al weet blijft bewaard, en wordt alleen opnieuw opgebouwd als de code die transcripts leest zelf verandert. Eén keer na deze update leest hij nog alles bij; daarna niet meer bij elke versie.
- `journal stop` kijkt nu naar het serverproces zelf, in plaats van te vragen of de server nog antwoordt. Een server die te druk is om te antwoorden, wordt dus ook echt gestopt; zo nodig sluit `journal stop` hem af.
- Er is een diagnostisch log. Zet in de viewer onder Settings, bij Dev faults, "Keep a diagnostic log" aan. Trage verzoeken en fouten komen dan in `.journal/runtime/diagnostics.log`. Hij staat standaard uit, zodat hij geen ruimte vult als je hem niet nodig hebt.

Updaten kan met `journal upgrade`, of je wacht op de automatische update.

Mocht je zoiets nog eens zien, zet dan het log aan en stuur me `diagnostics.log`. Dan zien we direct welk verzoek de tijd opslokt.

Groeten,

Jesse