Upstream-Sync 2026-11-05: Bericht (5.168 Commits, PR #11) #12

New issue

Open

opened 2026-11-05 23:57:20 +00:00 by alf · 1 comment

alf commented

2026-11-05 23:57:20 +00:00

Owner

Anlass

Regelmaessiger Upstream-Abgleich des Forks (NousResearch/hermes-agent -> iris/hermes-agent), angestossen mit sync-upstream; die Konfliktoesung lief von Hand ueber einen Merge-Branch (PR #11).

Stand vorher -> nachher

Fork origin/main: fcc357cbaa (Stand 2026-10-22, zweiter Re-Sync)
upstream/main beim Loslegen: e76fbd80be65; beim Einreichen: 79658be93ba3 (Upstream schob waehrend der Arbeit 71 weitere Commits, sauber nachgemergelt)
.fork-upstream-base: 944c3a434071 -> 79658be93ba3 (im Sync-Branch mitcommittet)
Umfang: 5.168 Upstream-Commits (2026-10-22 -> 2026-11-05), 5.778 Dateien, +345k/-119k Zeilen; 43 eigene Commits bleiben unveraendert (Merge-Commits, nie Rebase)

Konflikte und Loesungen

README.md (3 Hunks): Fork-Doku behalten — Upstream hatte nur sein Marketing-README umformuliert (Backends-Liste, OpenClaw->import-agent); das Original lebt in UPSTREAM-README.md. Gleichartige Entscheidung wie bei allen bisherigen Syncs.
tools/terminal_tool.py (1 Hunk): rein strukturell — Upstream wickelt den Call-Body neu in with _call_in_flight(plan.effective_task_id, task_id). Die server/client-session_key-Trennung (2026-08-19, cwd-Leak server->client) mit neuer Einrückung innerhalb des Blocks wieder eingesetzt; Semantik unveraendert.
Inhaltliche Neuanpassung (kein Konflikt, aber Noetigung): Upstream fuehrte Auto-Backgrounding ein (Trailing-& -> auto_backgrounded; Foreground-Timeout ueber Cap -> Hoeherstufung mit notify_on_complete). Der Early-Exit-Report (2026-10-07) kam den von Upstream-Tests festgenagelten Resultat-Formen zuvor und ueberdeckte sie. Jetzt auf die STILLE background-Form beschraenkt (not auto_backgrounded and not notify_on_complete and not watch_patterns): der Originalvorfall war genau ein stiller background=true-Lauf, ein konvertierter/hohergestufter Spawn meldet sein Ende ueber das Completion-Event. Beide Absichten ueberleben.

Ausgefuehrte Tests (Ergebnis)

compileall ueber alle 10.757 Python-Dateien des Merge-Ergebnisses: 0 Fehler
Smoke (Python-3.14-venv via uv — plain pip kann den Pillow/browser-harness-Pin nicht aufloesen, Upstream loest ihn nur ueber [tool.uv] override-dependencies; Kern-Deps sind per Marker an >=3.14 gebunden): Importe aller gepatchten Module OK, hermes --help ok — nach beiden Merges
Fork-Regressionstests (13 Fork-eigene Testdateien): 159 passed / 11 skipped
Upstream-Tools-Suite (Terminal/cwd/session-Slice): erste Runde 20 Failures — 17 byte-identisch auf einem sauberen upstream/main-Worktree mit eigenem uv-venv (umgebungsbedingt, Mac-spezifisch); die anderen 3 waren die Auto-Background-Kollision (Punkt 3 oben). Nach dem Re-fit: Failure-Menge IDENTISCH zur Upstream-Basis (17, gleiche Test-IDs).
Gateway-Suite -k run: Fork 16F+2E vs. Upstream-Basis 11F+2E. Die 11+2 identisch (umgebungsbedingt; lark_oapi ist eine optionale, nicht installierte Dep). Die 5 Differenz-Failures (test_api_authority_controls/_execution/_runs, test_native_ingress_trust, test_session_policy) sind VORBESTEHEND: sie schlagen auf origin/main (fcc357cbaa, also vor diesem Merge) in demselben venv bereits fehl und bestehen auf reinem Upstream. Cause: der Fork-Stall-Judge (2026-10-07) setzt bei jedem self-hosted Reply einen zusätzlichen CONTINUE/FINAL-Klassifizierungs-Request an die eigene Endpoint; diese Tests pruefen exakte Wire-Shape/Anzahl der Requests eines Runs gegen einen local-wire-stub und sehen den Judge-Request als unerwarteten System-Turn. KEINE Regression dieses Syncs.
Agent-Tests, die die vier gepatchten Agent-Dateien beruehren (stall guards/judge, history hygiene, turn finalizer, reply-line): 128 passed

Was schiefging

Der dokumentierte Smoke-Test-Weg (README: python3.12 -m venv + pip install -e .) ist faktisch gebrochen: aelteres Python installiert die Kern-Deps nicht (Marker >=3.14), und plain pip scheitert auf 3.14 an ERROR: Cannot install hermes-agent and hermes-agent==0.0.0 ... hermes-agent depends on Pillow==13.0.0; browser-harness depends on pillow==12.3.0. Weg ist uv (respektiert [tool.uv] override-dependencies). README entsprechend korrigiert.
Voll-Suite-Laeufe brachen mit SIGILL bzw. einem haengenden Test (logging-watchdog-teardown in hermes_state) ab; auf targeted Slices + Upstream-Gegenpruefung umgestellt. Dieselbe Hangaender-Form besteht schon auf dem Fork-Vorstand.

Nicht geprueft

Live-Test (echter Job durch den laufenden Mac-Gateway) — steht aus; nach dem Mergen nachziehen, bevor Produktion gezogen wird
Linux-Container (iris-hermes/iris-hermes-scheduled) noch nicht nachgezogen
Komplette tests/agent- und tests/gateway-Suiten (nur Slices, Gruende oben)
npm/JS-Teil des Repos (tests-js) nicht angeruehrt

Offene Punkte

Soll der Stall-Judge Laeufe gegen Stub-Endpoints / ohne angebotene Tools ueberspringen? (entschaerft die 5 vorbestehenden Testkollisionen; production-seitig unveraendert gewollt)
PR #11 mit „Merge“ (Merge-Commit) mergen — nie „Rebase“, und nicht mit ship.

## Anlass Regelmaessiger Upstream-Abgleich des Forks (NousResearch/hermes-agent -> iris/hermes-agent), angestossen mit `sync-upstream`; die Konfliktoesung lief von Hand ueber einen Merge-Branch (PR #11). ## Stand vorher -> nachher - Fork `origin/main`: `fcc357cbaa` (Stand 2026-10-22, zweiter Re-Sync) - `upstream/main` beim Loslegen: `e76fbd80be65`; beim Einreichen: `79658be93ba3` (Upstream schob waehrend der Arbeit 71 weitere Commits, sauber nachgemergelt) - `.fork-upstream-base`: `944c3a434071` -> `79658be93ba3` (im Sync-Branch mitcommittet) - Umfang: 5.168 Upstream-Commits (2026-10-22 -> 2026-11-05), 5.778 Dateien, +345k/-119k Zeilen; 43 eigene Commits bleiben unveraendert (Merge-Commits, nie Rebase) ## Konflikte und Loesungen 1. **README.md** (3 Hunks): Fork-Doku behalten — Upstream hatte nur sein Marketing-README umformuliert (Backends-Liste, OpenClaw->`import-agent`); das Original lebt in `UPSTREAM-README.md`. Gleichartige Entscheidung wie bei allen bisherigen Syncs. 2. **tools/terminal_tool.py** (1 Hunk): rein strukturell — Upstream wickelt den Call-Body neu in `with _call_in_flight(plan.effective_task_id, task_id)`. Die server/client-`session_key`-Trennung (2026-08-19, cwd-Leak server->client) mit neuer Einrückung innerhalb des Blocks wieder eingesetzt; Semantik unveraendert. 3. **Inhaltliche Neuanpassung (kein Konflikt, aber Noetigung):** Upstream fuehrte Auto-Backgrounding ein (Trailing-& -> `auto_backgrounded`; Foreground-Timeout ueber Cap -> Hoeherstufung mit `notify_on_complete`). Der Early-Exit-Report (2026-10-07) kam den von Upstream-Tests festgenagelten Resultat-Formen zuvor und ueberdeckte sie. Jetzt auf die STILLE background-Form beschraenkt (`not auto_backgrounded and not notify_on_complete and not watch_patterns`): der Originalvorfall war genau ein stiller `background=true`-Lauf, ein konvertierter/hohergestufter Spawn meldet sein Ende ueber das Completion-Event. Beide Absichten ueberleben. ## Ausgefuehrte Tests (Ergebnis) - `compileall` ueber alle 10.757 Python-Dateien des Merge-Ergebnisses: 0 Fehler - Smoke (Python-3.14-venv via **uv** — plain pip kann den Pillow/browser-harness-Pin nicht aufloesen, Upstream loest ihn nur ueber `[tool.uv] override-dependencies`; Kern-Deps sind per Marker an >=3.14 gebunden): Importe aller gepatchten Module OK, `hermes --help` ok — nach beiden Merges - Fork-Regressionstests (13 Fork-eigene Testdateien): 159 passed / 11 skipped - Upstream-Tools-Suite (Terminal/cwd/session-Slice): erste Runde 20 Failures — 17 byte-identisch auf einem sauberen `upstream/main`-Worktree mit eigenem uv-venv (umgebungsbedingt, Mac-spezifisch); die anderen 3 waren die Auto-Background-Kollision (Punkt 3 oben). Nach dem Re-fit: Failure-Menge IDENTISCH zur Upstream-Basis (17, gleiche Test-IDs). - Gateway-Suite `-k run`: Fork 16F+2E vs. Upstream-Basis 11F+2E. Die 11+2 identisch (umgebungsbedingt; `lark_oapi` ist eine optionale, nicht installierte Dep). Die 5 Differenz-Failures (`test_api_authority_controls/_execution/_runs`, `test_native_ingress_trust`, `test_session_policy`) sind VORBESTEHEND: sie schlagen auf `origin/main` (fcc357cbaa, also vor diesem Merge) in demselben venv bereits fehl und bestehen auf reinem Upstream. Cause: der Fork-Stall-Judge (2026-10-07) setzt bei jedem self-hosted Reply einen zusätzlichen CONTINUE/FINAL-Klassifizierungs-Request an die eigene Endpoint; diese Tests pruefen exakte Wire-Shape/Anzahl der Requests eines Runs gegen einen `local-wire-stub` und sehen den Judge-Request als unerwarteten System-Turn. KEINE Regression dieses Syncs. - Agent-Tests, die die vier gepatchten Agent-Dateien beruehren (stall guards/judge, history hygiene, turn finalizer, reply-line): 128 passed ## Was schiefging - Der dokumentierte Smoke-Test-Weg (README: `python3.12 -m venv` + `pip install -e .`) ist faktisch gebrochen: aelteres Python installiert die Kern-Deps nicht (Marker `>=3.14`), und plain pip scheitert auf 3.14 an `ERROR: Cannot install hermes-agent and hermes-agent==0.0.0 ... hermes-agent depends on Pillow==13.0.0; browser-harness depends on pillow==12.3.0`. Weg ist uv (respektiert `[tool.uv] override-dependencies`). README entsprechend korrigiert. - Voll-Suite-Laeufe brachen mit SIGILL bzw. einem haengenden Test (logging-watchdog-teardown in `hermes_state`) ab; auf targeted Slices + Upstream-Gegenpruefung umgestellt. Dieselbe Hangaender-Form besteht schon auf dem Fork-Vorstand. ## Nicht geprueft - Live-Test (echter Job durch den laufenden Mac-Gateway) — steht aus; nach dem Mergen nachziehen, bevor Produktion gezogen wird - Linux-Container (`iris-hermes`/`iris-hermes-scheduled`) noch nicht nachgezogen - Komplette `tests/agent`- und `tests/gateway`-Suiten (nur Slices, Gruende oben) - npm/JS-Teil des Repos (tests-js) nicht angeruehrt ## Offene Punkte - Soll der Stall-Judge Laeufe gegen Stub-Endpoints / ohne angebotene Tools ueberspringen? (entschaerft die 5 vorbestehenden Testkollisionen; production-seitig unveraendert gewollt) - PR #11 mit „Merge“ (Merge-Commit) mergen — nie „Rebase“, und nicht mit `ship`.

alf added the

typ

docs

label

2026-11-05 23:58:18 +00:00

alf commented

2026-11-06 03:03:03 +00:00

Author

Owner

Live-Nachzug 2026-11-06 — gemergt und in Produktion verifiziert

origin/main = 4178d092d0 (Doku nachgezogen, PR #13); Sync-Inhalt d80b3536d4.

Mac (dieser Rechner): ~/.hermes/hermes-agent per git pull auf d80b3536d, Gateway per launchctl kickstart -k gui/$(id -u)/ai.hermes.gateway neu gestartet (/health nach 5 s ok). Echter Job: POST /v1/runs ohne Modellangabe (Default-Backend llama-server :18200) → status completed, output „OK", über den admission-Pfad (admission_id gesetzt). Hinweis: die iris-splash-Route (:18100) war nicht erreichbar — ein Testlauf mit model: iris-splash endete korrekt mit failed + klarer Fehlermeldung („Connection error", nach 3 Versuchen), also auch der Fehlerpfad lebend bestätigt.

Linux (alf@iris-server): Canary Test-Iris (:8766) zuerst, dann Produktiv iris-server (:8765), je beide Hermes-Container per POST /hermes/agent/update auf d80b3536d. Echte /agent-Jobs → completed, Antwort „OK", ~33 s (vLLM :8080).

Zwei Betriebsbefunde — keiner davon eine Fork-Regression:

Die Test-Instanz hatte nie einen IRIS-ADMIN-CONFIG-Block (GET /config zeigte leeres Backend/Modell, auch im Config-Backup vom 21.10. keiner) — ihr api_server bindete darum 127.0.0.1 und der erste Canary-Job hing. Behoben auf dem vorgesehenen Weg: POST /config mit dem Backend der Produktivinstanz (openaicompat qwen3.8-flash-next-iq3_s, http://192.168.178.153:8080) — Bind wieder 0.0.0.0, Job grün. Die 127.0.0.1-Bindung war vor dem Update identisch (DEFAULT_HOST unverändert), der Hänger ist also kein Sync-Schaden, sondern eine unvollständig konfigurierte Test-Instanz.
Auf Produktion hing der erste Job nach dem Update (running, obwohl der Gateway gesund auf 0.0.0.0 lauschte): der seit 3 Tagen laufende iris-server-Container brachte keinen einzigen Request an Hermes raus (kein POST /v1/runs im Gateway-Access-Log, kein Traceback im Server) — verbrannte Pooled-Verbindungen gegen den beim Update neu gebauten Hermes-Container. docker compose restart server behebt es; danach completed in 33 s. Offener Punkt (linux-server): Timeout/Fehler statt endlosem running, wenn Hermes nicht erreichbar — genau die Fehlerklasse, die dieser Fork abschaffen will, hier auf der Server-Seite.

Nicht geprüft: iOS-Clients gegen die aktualisierten Server; Cron-/Scheduled-Jobs aktiv ausgelöst (Container laufen, Gateway unauffällig).

## Live-Nachzug 2026-11-06 — gemergt und in Produktion verifiziert `origin/main` = `4178d092d0` (Doku nachgezogen, PR #13); Sync-Inhalt `d80b3536d4`. **Mac (dieser Rechner):** `~/.hermes/hermes-agent` per `git pull` auf `d80b3536d`, Gateway per `launchctl kickstart -k gui/$(id -u)/ai.hermes.gateway` neu gestartet (`/health` nach 5 s ok). Echter Job: `POST /v1/runs` ohne Modellangabe (Default-Backend llama-server :18200) → `status completed`, output „OK", über den admission-Pfad (`admission_id` gesetzt). Hinweis: die `iris-splash`-Route (:18100) war nicht erreichbar — ein Testlauf mit `model: iris-splash` endete korrekt mit `failed` + klarer Fehlermeldung („Connection error", nach 3 Versuchen), also auch der Fehlerpfad lebend bestätigt. **Linux (alf@iris-server):** Canary `Test-Iris` (:8766) zuerst, dann Produktiv `iris-server` (:8765), je beide Hermes-Container per `POST /hermes/agent/update` auf `d80b3536d`. Echte `/agent`-Jobs → `completed`, Antwort „OK", ~33 s (vLLM :8080). **Zwei Betriebsbefunde — keiner davon eine Fork-Regression:** 1. Die Test-Instanz hatte **nie** einen `IRIS-ADMIN-CONFIG`-Block (`GET /config` zeigte leeres Backend/Modell, auch im Config-Backup vom 21.10. keiner) — ihr api_server bindete darum 127.0.0.1 und der erste Canary-Job hing. Behoben auf dem vorgesehenen Weg: `POST /config` mit dem Backend der Produktivinstanz (openaicompat qwen3.8-flash-next-iq3_s, http://192.168.178.153:8080) — Bind wieder 0.0.0.0, Job grün. Die 127.0.0.1-Bindung war vor dem Update identisch (DEFAULT_HOST unverändert), der Hänger ist also kein Sync-Schaden, sondern eine unvollständig konfigurierte Test-Instanz. 2. Auf **Produktion** hing der erste Job nach dem Update (`running`, obwohl der Gateway gesund auf 0.0.0.0 lauschte): der seit 3 Tagen laufende `iris-server`-Container brachte **keinen einzigen** Request an Hermes raus (kein `POST /v1/runs` im Gateway-Access-Log, kein Traceback im Server) — verbrannte Pooled-Verbindungen gegen den beim Update neu gebauten Hermes-Container. `docker compose restart server` behebt es; danach completed in 33 s. **Offener Punkt (linux-server):** Timeout/Fehler statt endlosem `running`, wenn Hermes nicht erreichbar — genau die Fehlerklasse, die dieser Fork abschaffen will, hier auf der Server-Seite. **Nicht geprüft:** iOS-Clients gegen die aktualisierten Server; Cron-/Scheduled-Jobs aktiv ausgelöst (Container laufen, Gateway unauffällig).