1:1-Spiegel aus dem Repo
Quelle: zulieferung/incidents/W6_INCIDENT_20260807_WD_AUTODISABLE_MITTERNACHT.md · Stand der Quelldatei: 08.08.2026 09:35 · erzeugt: 14.08.2026 00:33
Diese Seite ist eine wortgetreue Kopie. Geaendert wird immer die Quelldatei, nie diese Seite.
INCIDENT 20260807 — Watchdog schaltet EIA zweimal faelschlich ab (Ack-Rennen + Mitternachts-Signatur)¶
Severity: HOCH · Status: BEOBACHTEN (Fix beauftragt: T2-B5 erweitert; 2. Vorfall 08.08. 02:30) · Entdeckt von: M (Board) · Diagnose: G (UTC-Beweis + fail_streak-Analyse) · Loesung: T2 (ausstehend)
| Status | ZU (07.08.2026 ~02:16; Dauer-Fix in Arbeit: T2 Runde 5, B5) |
| Aufgetreten | 06.08. 23:00:53 (#1) und 07.08. 02:00:53 (#2) · Entdeckt: 07.08. 00:25 bzw. 02:10 durch G-Forensik |
| System | W6-WD Watchdog (n8n) + gov_act/ICP-Kette |
| Symptom | EIA-Agent steht unerwartet auf AUS; Ms Board-Klicks scheinen "nicht zu halten"; Test-Angebot wird nicht versendet |
| Auswirkung | EIA arbeitslos 23:00-00:29 (89 min) und 02:00-02:16 (16 min); Ms End-to-End-Test um Stunden verzoegert; kein Kundenschaden (nachts, keine Tickets) |
| Fallbeispiel | gov_actions id 26/28 (#1), id 37/38 (#2); Guard-Block run 143 "G1:kill_switch(agent)"; Ticket 6295 / Angebot S37807 |
1. Zeitachse (Berlin; UTC in Klammern)¶
- 06.08. 22:15 — Hetzner-Reboot-Incident (separat dokumentiert) erzeugt 3 EIA-Fehllaeufe 122-124 (E3:icp_unreadable)
- 23:00:53 (21:00:53Z) — WD-Stundenlauf: fail_streak >= 3 -> disable_agent eia (Audit id 26) + WD-Selbst-Ack Signatur fail_streak:eia:2026-08-06 (id 27)
- 23:05:24 — Gs Vorab-Ack (id 28) kommt 4,5 min ZU SPAET — das Rennen war verloren, bevor es begann
- 00:17-00:29 — M schaltet VKA und EIA per Board wieder ein (ids 30/33); Kacheln zeigen es wegen Spiegel-Alter nicht (separater Board-Befund)
- 01:48 — EIA legt Angebots-Entwurf S37807 an (run 140) — Agent arbeitet
- 02:00:53 (00:00:53Z!) — ERSTER WD-Lauf nach UTC-MITTERNACHT: Tages-Signatur kippt auf :2026-08-07, gestriges Ack wirkungslos, dieselben 3 Fehllaeufe noch im 24h-Fenster -> disable #2 (id 37) + neues Selbst-Ack (id 38)
- 02:03:09 — Guard blockt Ankunfts-Vermerk+Versand: G1:kill_switch(agent) (run 143)
- 02:16 — M schaltet EIA in der Odoo-UI wieder ein (direkter ICP-Write, daher ohne Audit-Zeile)
- 02:18:21 — Versand S37807 erfolgreich (run 147); seither fehlerfrei (Fruehlage 06:50)
2. Ursachenkette¶
- AUSLOESER: 3 legitime Infrastruktur-Fehllaeufe (Hetzner-Reboot) im errors_24h-Fenster.
- DESIGNLUECKE A (Rennen): Vorab-Acks wurden erst nach der Incident-BEHEBUNG gesetzt; der stuendliche WD-Lauf kam frueher.
- DESIGNLUECKE B (Mitternacht): Ack-Signatur ist an das KALENDERDATUM gebunden — und zwar in UTC (Berliner Mitternachts-Laeufe 00:00/01:00 disablten NICHT, der 02:00-Lauf = 00:00Z schon). Jedes Ack verfaellt zur UTC-Mitternacht, solange die Fehler im 24h-Fenster liegen.
- VERSTAERKER (Sichtbarkeit): Auto-Disable erzeugt keinen Alarm; #1 blieb 85 min unbemerkt (Befund B3 -> D-049).
3. Loesungsansaetze¶
| Ansatz | Bewertung | Entscheidung |
|---|---|---|
| Ack wirkt 24h AB ERTEILUNG (Zeitfenster statt Kalendertag) | robust, zeitzonenfrei | GEWAEHLT (B5-Fix, T2 R5) |
| errors_24h zaehlt nur UNGEACKTE Fehler | gleichwertig, etwas groesserer Umbau | Alternative, T2 entscheidet im Bau |
| WD-Zeitlogik komplett auf Europe/Berlin | noetig fuer Konsistenz (F18-Nachzieher) | GEWAEHLT (zusaetzlich) |
| fail_streak-Schwelle erhoehen | kaschiert nur, Wache wird blind | verworfen |
| Auto-Disable abschaffen | nimmt dem Waechter den Zweck | verworfen; stattdessen D-049-Alarm |
4. Durchgefuehrte Loesung + Rollback¶
Sofort: M re-enable (Board 00:29 / Odoo-UI 02:16); Wiederholung fuer den 07.08. ausgeschlossen (WD-Selbst-Ack id 38 deckt den Tag; ab 08.08. 00:00 sind die Fehllaeufe aus dem Fenster). Dauerhaft: T2 Runde 5 = WD v0.2.3 mit 24h-Ack + Berlin-Zeitlogik + Harness-Beweis "Mitternachtsfall ohne disable". Rollback des Fixes: WD-Version zurueck (n8n-Versionierung).
5. Erkennung kuenftig¶
- SELECT id, actor, action, agent_id, created_at FROM w6a.gov_actions WHERE action='disable_agent' AND actor LIKE 'w6-%' ORDER BY created_at DESC LIMIT 5; -- Auto-Disables sofort sichtbar
- run_log-Signatur: step='arrival:guard_block' + message LIKE '%kill_switch%' = Agent laeuft, darf aber nicht schreiben -> IMMER Schalter-Wahrheit in Odoo pruefen, nie der Kachel glauben
- D-049 (Status-Seite): Handy-Alarm auf jede disable_agent/emergency_stop-Zeile
6. Lessons + Folgepunkte¶
- Freibriefe SOFORT bei Incident-BEGINN setzen, nicht nach der Behebung (Vorab-Ack-Timing, B1).
- Zwei Uhren in einem Waechter (UTC-Datum vs. Berlin-Anzeige) sind ein Konsistenzfehler — Zeitzonen-Audit gehoert in jeden Zeitlogik-Review.
- "n8n-Workflow gruen" heisst nicht "Agent arbeitet" — Gate-Laeufe sehen identisch aus; Arbeit belegt nur das run_log.
- OFFEN: B5-Fix + Harness-Beweis (T2, WD v0.2.3) · D-049-Alarm (nach Board R9) · B1-Timing-Regel in FLEET_REGELN (T2)
NACHTRAG 08.08.2026 — WIEDERHOLUNG mit neuem Muster (fail_streak)¶
02:30 Uhr (00:30 UTC): WD schaltet EIA UND VKA erneut fälschlich ab. Diesmal NICHT die Tages-Signatur allein, sondern fail_streak-Alarme (Signaturen fail_streak:eia/vka/gread:2026-08-08) — gefüttert von realen, aber transienten Fehlern des Vortags: Odoo-522-Aussetzer 22:03-22:48 (EIA 3x, VKA 1x) + drei G-READ-Fehlversuche (v19-Feldfehler, runs 206/208/209). Beim UTC-Tageswechsel wurde die Streak als "frisch" alarmiert → disable_agent eia + vka (gov_actions 00:30 UTC). Positiv-Beleg: Um 05:30 (03:30 UTC, run 303) blockte der kill_switch einen EIA-Bauversuch korrekt — die Not-Aus-Kette funktioniert wie designt. Folge: Eintausch-Ticket von 07:18 (05:18 UTC, run 313: "1 Ticket, 0 Angebote NEU") blieb unverarbeitet bis M-Wiedereinschalten.
Zusätzliche Ursachen-Facette: Werkzeug-Fehlversuche (gread) zählen in dieselbe Streak wie Agenten-Fehler — Werkzeuge (kind=werkzeug) sollten den WD-Streak NICHT füttern oder eine eigene, nicht-abschaltende Behandlung bekommen.
Konsequenz für T2-B5 (Erweiterung der bestehenden PRIO-Freigabe): (1) Zeitlogik Europe/Berlin + 24h-Ack ab Erteilung (wie freigegeben); (2) NEU: fail_streak nur aus Läufen der letzten X Stunden ROLLIEREND berechnen, nie über Tagesgrenzen als "neu" alarmieren; (3) NEU: kind='werkzeug' aus Streak/Disable ausnehmen; (4) NEU: disable_agent NUR bei Fehlern in VOLLZUGS-Phasen, nicht bei transienten Scan-/Verbindungsfehlern (522) unterhalb einer Dauer-Schwelle. Harness-Beweis um Fall "522-Fenster + Tageswechsel" erweitern.