Modul-16: Monitoring-FAIL-CLOSED-Fix dokumentiert (M15-Ausfall -> monitoring FAILED) - Rain Ocampo, 21.08.2026

This commit is contained in:
Rain Ocampo 2026-08-21 01:15:32 +00:00
parent d32987a1a7
commit 662ffe768e

View file

@ -97,6 +97,11 @@ Einzelne Quellen-Fehler (404/5xx/Timeout) werden über `_safe_get` als `{"_error
Teil-Ergebnis gekapselt → der Gesamt-Task bleibt SUCCEEDED. Nur wenn ein Service **komplett unreachable** Teil-Ergebnis gekapselt → der Gesamt-Task bleibt SUCCEEDED. Nur wenn ein Service **komplett unreachable**
(`UNREACHABLE`/`TIMEOUT`) ist, liefert er `None`. Write-Aktionen (Backtest/Optimization) bleiben strikt FAILED bei Fehlern. (`UNREACHABLE`/`TIMEOUT`) ist, liefert er `None`. Write-Aktionen (Backtest/Optimization) bleiben strikt FAILED bei Fehlern.
**Ausnahme — Monitoring (FAIL-CLOSED):** Der `monitoring`-Task ruft M15 **nicht** über `_safe_get`,
sondern direkt auf. M15 ist die autoritative Trading-Status-Quelle — ist sie nicht erreichbar, wird der
Monitoring-Task **FAILED** (kein „ok"-Status bei ausgefallenem M15). Bei M12/M13-Ausfall → betroffener
Task (Backtest/Optimization) FAILED, M16 bleibt healthy, Trading-Core unbeeinflusst.
## Tests & E2E-Verifikation (VPS, 21.08.2026) ## Tests & E2E-Verifikation (VPS, 21.08.2026)
- **Unit-Tests** `tests/test_paperclip.py`: 10/10 grün (ProposalGate-Safety, Task-Validierung, Worker, Idempotenz, Auto-Aktivierungs-Verbot). - **Unit-Tests** `tests/test_paperclip.py`: 10/10 grün (ProposalGate-Safety, Task-Validierung, Worker, Idempotenz, Auto-Aktivierungs-Verbot).
- **Backtest-Flow**: M16 → M12 `POST /backtest`**SUCCEEDED**, `agent_run` + `run_id`/`result_refs` korrekt (`kind:"backtest"`). - **Backtest-Flow**: M16 → M12 `POST /backtest`**SUCCEEDED**, `agent_run` + `run_id`/`result_refs` korrekt (`kind:"backtest"`).
@ -107,7 +112,9 @@ Teil-Ergebnis gekapselt → der Gesamt-Task bleibt SUCCEEDED. Nur wenn ein Servi
- **Proposal**: erstellt als `DRAFT`/`auto_activated=false`; `APPROVED` → 422. **NICHT auto-aktiviert.** - **Proposal**: erstellt als `DRAFT`/`auto_activated=false`; `APPROVED` → 422. **NICHT auto-aktiviert.**
- **Kein M09-Zugriff**: `task_type=execute_order` → 422; kein `ExecutionClient`, keine `/order`-Endpunkte, kein `execution_base_url`. - **Kein M09-Zugriff**: `task_type=execute_order` → 422; kein `ExecutionClient`, keine `/order`-Endpunkte, kein `execution_base_url`.
- **Kein M15-Override**: Paperclip hat nur GET-Methoden auf M15, keine Control-Write. - **Kein M15-Override**: Paperclip hat nur GET-Methoden auf M15, keine Control-Write.
- **Ausfall-Toleranz**: fehlende Daten/Fehler → Task FAILED, Container bleibt **healthy**; Container-Restart → healthy. - **Ausfall-Toleranz**: M12 down → backtest FAILED, M13 down → optimization FAILED, M15 down → monitoring
**FAILED (FAIL-CLOSED)**, M15 up → SUCCEEDED. M16 bleibt in allen Fällen **healthy**, Trading-Core unbeeinflusst,
Erholung → SUCCEEDED.
- **Idempotenz**: erneuter `run` erzeugt neuen `agent_run`, überschreibt frühere Runs nicht. - **Idempotenz**: erneuter `run` erzeugt neuen `agent_run`, überschreibt frühere Runs nicht.
- **Ungültige Aufgabe**: `task_type=delete_database` → 422. - **Ungültige Aufgabe**: `task_type=delete_database` → 422.
- **Keine Secrets in Logs/API**: `docker logs` frei von password/secret/token/api_key. - **Keine Secrets in Logs/API**: `docker logs` frei von password/secret/token/api_key.
@ -121,6 +128,10 @@ Teil-Ergebnis gekapselt → der Gesamt-Task bleibt SUCCEEDED. Nur wenn ein Servi
`IndexError`. Behoben: vollständige Spaltenliste. `IndexError`. Behoben: vollständige Spaltenliste.
4. **Research-Einzelfehler-Crash**: Einzelne fehlende Quelle (M04 404) failte den ganzen Research-Task. 4. **Research-Einzelfehler-Crash**: Einzelne fehlende Quelle (M04 404) failte den ganzen Research-Task.
Behoben: `_safe_get` kapselt Einzelquellen-Fehler, Task bleibt SUCCEEDED mit Teil-Ergebnissen. Behoben: `_safe_get` kapselt Einzelquellen-Fehler, Task bleibt SUCCEEDED mit Teil-Ergebnissen.
5. **Monitoring-FAIL-CLOSED (21.08.2026)**: `monitoring`-Task nutzte `_safe_get`, was M15-`UNREACHABLE`
zu `None` kapselte → Task blieb SUCCEEDED trotz ausgefallenem M15. Fix: `_monitoring` ruft M15 **direkt**
auf, damit ein M15-Ausfall als `ClientError` weiterfaellt und der Task **FAILED** wird. Verifiziert:
M15 down → monitoring FAILED, M15 up → SUCCEEDED.
## Compose / Betrieb ## Compose / Betrieb
- Netzwerk `trading-modules`, DB-Host `Modul-01-PostgreSQL` (Modul-01), Port 55016 nur intern (`expose`), - Netzwerk `trading-modules`, DB-Host `Modul-01-PostgreSQL` (Modul-01), Port 55016 nur intern (`expose`),
@ -132,5 +143,5 @@ Teil-Ergebnis gekapselt → der Gesamt-Task bleibt SUCCEEDED. Nur wenn ein Servi
``` ```
Geändert von: Rain Ocampo Geändert von: Rain Ocampo
Datum: 21.08.2026 Datum: 21.08.2026
Grund: Modul-16-Paperclip implementiert + E2E verifiziert (Backtest/Optimization/Monitoring/Research/Strategy-Success, Safety 422, ProposalGate, Ausfall-toleranz, Idempotenz). Noch NICHT FREIGEGEBEN — bis E2E final grün. Modul-17 NICHT begonnen. Grund: Modul-16-Paperclip implementiert + E2E verifiziert (Backtest/Optimization/Monitoring/Research/Strategy-Success, Safety 422, ProposalGate, Ausfall-toleranz, Idempotenz). Monitoring-FAIL-CLOSED-Fix: M15-Ausfall -> monitoring-Task FAILED statt SUCCEEDED. Noch NICHT FREIGEGEBEN — bis E2E final grün. Modul-17 NICHT begonnen.
``` ```