Hermes-Folgefrage hängt: session_meta mit content null im Sitzungsverlauf #147

New issue

Closed

opened 2026-10-22 12:15:42 +00:00 by alf · 1 comment

alf commented

2026-10-22 12:15:42 +00:00

Owner

Befund

Folgefragen in Hermes-Chats bleiben auf „Das Modell arbeitet seit …“ stehen. Die erste Nachricht eines Chats funktioniert. Aufgetreten am 2026-10-22 nach dem Hermes-Upstream-Sync (iris/hermes-agent#9).

Ursache

GET /api/sessions/{id}/messages liefert seit dem Sync zusätzlich einen Eintrag {"role": "session_meta", "content": null, ...} (und display_kind an Nachrichten). In AgentJob.swift (Folgefrage, Verlauf aus sessionMessages umbauen) läuft bei content == null JSONSerialization.data(withJSONObject: NSNull()). Das wirft eine Objective-C-Exception („Invalid top-level type in JSON write“), die try? nicht abfängt; im isolierten Test beendet sie das Programm sofort.

Belege: Das Iris-Log endet nach „Canvas-Watcher gestartet“; die Meldung „Nachrichten aus gespeicherter Session-Historie geladen“ fehlt. Hermes sah nur die Verlaufsabfrage (200), nie ein POST /v1/runs; keine offene Verbindung zu 127.0.0.1:8642, Backend im Leerlauf. Warum die App dabei nicht abstürzt, ist ungeklärt.

Warum

Jede Folgefrage in jedem Hermes-Chat ist betroffen, solange der Verlauf einen solchen Eintrag enthält.

Vorgehen

Einträge mit anderen Rollen als system/user/assistant/tool beim Umbau des Verlaufs überspringen; NSNull und nicht JSON-fähige Werte als leeren Inhalt behandeln, ohne JSONSerialization aufzurufen.

Offen

Ob Linux-Server und Remote-Clients denselben Eintrag verarbeiten, ist nicht geprüft.

## Befund Folgefragen in Hermes-Chats bleiben auf „Das Modell arbeitet seit …“ stehen. Die erste Nachricht eines Chats funktioniert. Aufgetreten am 2026-10-22 nach dem Hermes-Upstream-Sync (iris/hermes-agent#9). ## Ursache `GET /api/sessions/{id}/messages` liefert seit dem Sync zusätzlich einen Eintrag `{"role": "session_meta", "content": null, ...}` (und `display_kind` an Nachrichten). In `AgentJob.swift` (Folgefrage, Verlauf aus `sessionMessages` umbauen) läuft bei `content == null` `JSONSerialization.data(withJSONObject: NSNull())`. Das wirft eine Objective-C-Exception („Invalid top-level type in JSON write“), die `try?` nicht abfängt; im isolierten Test beendet sie das Programm sofort. Belege: Das Iris-Log endet nach „Canvas-Watcher gestartet“; die Meldung „Nachrichten aus gespeicherter Session-Historie geladen“ fehlt. Hermes sah nur die Verlaufsabfrage (200), nie ein `POST /v1/runs`; keine offene Verbindung zu 127.0.0.1:8642, Backend im Leerlauf. Warum die App dabei nicht abstürzt, ist ungeklärt. ## Warum Jede Folgefrage in jedem Hermes-Chat ist betroffen, solange der Verlauf einen solchen Eintrag enthält. ## Vorgehen Einträge mit anderen Rollen als system/user/assistant/tool beim Umbau des Verlaufs überspringen; `NSNull` und nicht JSON-fähige Werte als leeren Inhalt behandeln, ohne `JSONSerialization` aufzurufen. ## Offen Ob Linux-Server und Remote-Clients denselben Eintrag verarbeiten, ist nicht geprüft.

alf added the

typ

bug

label

2026-10-22 12:15:42 +00:00

alf referenced this issue

2026-10-22 12:16:26 +00:00

fix(hermes): Folgefrage hängt nicht mehr an session_meta mit content null im Verlauf (#147) #148

alf referenced this issue from a commit

2026-10-22 12:16:27 +00:00

fix(hermes): Folgefrage hängt nicht mehr an session_meta mit content null im Verlauf (#147)

alf commented

2026-10-22 12:16:27 +00:00

Author

Owner

PR #148 gemergt: fix(hermes): Folgefrage hängt nicht mehr an session_meta mit content null im Verlauf (#147)
#148

Commits:

fix(hermes): Folgefrage hängt nicht mehr an session_meta mit content null im Verlauf (#147)

Stand

Befund: Hermes-Folgefragen blieben auf „Das Modell arbeitet seit …“ stehen. Seit dem Hermes-Sync (iris/hermes-agent#9) liefert GET /api/sessions/{id}/messages einen Eintrag {"role": "session_meta", "content": null}. Beim Umbau des Verlaufs in AgentJob.swift rief Iris dafür JSONSerialization.data(withJSONObject: NSNull()) auf. Das wirft eine Objective-C-Exception, die try? nicht abfängt. Das Iris-Log endete danach, Hermes bekam nie ein POST /v1/runs.

Geändert: AgentJob.swift, Verlauf für die Folgefrage: nur Rollen system/user/assistant/tool werden übernommen (session_meta entfällt); Inhalt, der kein gültiges JSON-Objekt ist (z. B. NSNull), wird zu einem leeren String, ohne JSONSerialization aufzurufen.

Geprüft:

Isoliertes Swift-Programm mit der echten Hermes-Antwort des betroffenen Chats: 3 Roheinträge ergeben 2 Verlaufseinträge (user, assistant); NSNull ergibt leeren Inhalt, strukturierter Inhalt wird weiter serialisiert.
Derselbe Aufruf ohne die Änderung beendet ein Testprogramm sofort mit NSInvalidArgumentException.

Nicht geprüft: Kein Build der App und keine echte Folgefrage im laufenden Iris (xcodebuild im Terminal ist laut CLAUDE.md verboten, der Build per Xcode startet Iris neu). Linux-Server und Remote-Clients (iOS, IrisClient) mit demselben session_meta-Eintrag nicht untersucht. Warum die App beim Ausnahmefall nicht abstürzt, sondern der Job hängt, ist ungeklärt.

Grenzen: Die Änderung filtert nach einer Rollenliste; kommt eine neue legitime Rolle hinzu, müsste sie dort ergänzt werden.

Offen: Bauen, Iris neu starten und eine Folgefrage in einem Hermes-Chat von Hand ausprobieren; deshalb status/zu-testen.

PR #148 gemergt: fix(hermes): Folgefrage hängt nicht mehr an session_meta mit content null im Verlauf (#147) https://forgejo.lewerken.duckdns.org/iris/Iris/pulls/148 Commits: - fix(hermes): Folgefrage hängt nicht mehr an session_meta mit content null im Verlauf (#147) --- ## Stand **Befund:** Hermes-Folgefragen blieben auf „Das Modell arbeitet seit …“ stehen. Seit dem Hermes-Sync (iris/hermes-agent#9) liefert `GET /api/sessions/{id}/messages` einen Eintrag `{"role": "session_meta", "content": null}`. Beim Umbau des Verlaufs in `AgentJob.swift` rief Iris dafür `JSONSerialization.data(withJSONObject: NSNull())` auf. Das wirft eine Objective-C-Exception, die `try?` nicht abfängt. Das Iris-Log endete danach, Hermes bekam nie ein `POST /v1/runs`. **Geändert:** `AgentJob.swift`, Verlauf für die Folgefrage: nur Rollen system/user/assistant/tool werden übernommen (`session_meta` entfällt); Inhalt, der kein gültiges JSON-Objekt ist (z. B. `NSNull`), wird zu einem leeren String, ohne `JSONSerialization` aufzurufen. **Geprüft:** - Isoliertes Swift-Programm mit der echten Hermes-Antwort des betroffenen Chats: 3 Roheinträge ergeben 2 Verlaufseinträge (`user`, `assistant`); `NSNull` ergibt leeren Inhalt, strukturierter Inhalt wird weiter serialisiert. - Derselbe Aufruf ohne die Änderung beendet ein Testprogramm sofort mit `NSInvalidArgumentException`. **Nicht geprüft:** Kein Build der App und keine echte Folgefrage im laufenden Iris (`xcodebuild` im Terminal ist laut CLAUDE.md verboten, der Build per Xcode startet Iris neu). Linux-Server und Remote-Clients (iOS, IrisClient) mit demselben `session_meta`-Eintrag nicht untersucht. Warum die App beim Ausnahmefall nicht abstürzt, sondern der Job hängt, ist ungeklärt. **Grenzen:** Die Änderung filtert nach einer Rollenliste; kommt eine neue legitime Rolle hinzu, müsste sie dort ergänzt werden. **Offen:** Bauen, Iris neu starten und eine Folgefrage in einem Hermes-Chat von Hand ausprobieren; deshalb `status/zu-testen`.

alf

2026-10-22 12:16:27 +00:00