Samstag, 5. September 2026

Problem: `deep-paraphrase-check.py` bricht bei jedem Aufruf ab: „upstream call failed: Connect: Too many open files (os error 24)". Betrifft alle drei heute geschriebenen ASTS-Entwuerfe. Die Pruefung ist laut IDIOMATIK-X-DEEP Abschnitt 6.5 Pflicht, nicht Kuer, und ist die einzige der vier, die einen inhaltlichen Aufguss bei anderem Wortlaut findet

Ursache: **OFFEN — nicht abschliessend geklaert.** Ausgeschlossen ist die lokale Shell: `ulimit -n` steht bei 1.048.576, systemweit sind 4.672 Deskriptoren offen, die langlaufenden Node-Prozesse halten 22 bis 25. Der Dienst meldet sich selbst als erreichbar („Dienst: ok — 2 Modelle verfuegbar"), der Fehler entsteht erst beim Upstream-Verbindungsaufbau. Ein Neustart des Gateways wurde bewusst unterlassen, weil laufende Prozesse nicht ungefragt angefasst werden

Fix: Ersatzweise von Hand geprueft und das Ergebnis mitgeliefert statt verschwiegen: bei zwei Entwuerfen keine Naehe zu Gelaufenem, bei einem (ASIC/Verarbeitungsbandbreite) eine thematische Nachbarschaft zum Aperture-Kurzpost vom 04.09., die im Telegram-Kopf ausdruecklich benannt ist. Kein Entwurf wurde als geprueft ausgegeben, der es nicht ist. **Test:** nicht testbar im eigenen Code -- der Fehler entsteht im Upstream eines fremden Dienstes. Was testbar waere und fehlt: dass ein ausgefallener Pflichtcheck die Abgabe blockiert statt sie stillschweigend passieren zu lassen

Problem: Der Bilder-Auftrag fuer 73 Pins nannte als naechsten Check 05.09. 12:00 Europe/Berlin. Um 13:25 war das Fenster verstrichen, geliefert wurde nichts, und der Zustand zeigte weiter "0 Versuche, weiter". Der zweite Auftrag (Herbst-Pins) lag seit 16 Stunden unbearbeitet

Ursache: Meldet ein Bot `blocked` mit `wartet_auf`, bleibt sein Auftrag im Zustand offen -- richtig, er hat nicht versagt. Das Inbox-Item wandert aber ins Archiv. Damit stand der Auftrag nirgends mehr, wo ein Bot ihn sieht: Er wartete auf einen Takt, zu dem ihn niemand weckt, und waere nach 72 Stunden als gescheitert eskaliert, ohne je bearbeitet worden zu sein. Das Feld `wieder_aufnehmen_ab` stand im Zustand und wurde von keinem Werkzeug gelesen

Fix: `scripts/auftrag-wiedervorlage.mjs` legt faellige Auftraege zurueck in die Inbox, Cron alle 30 Minuten. Der Bilder-Auftrag wurde sofort vorgelegt. Meldet bewusst nur, wenn die Vorlage scheitert -- eine geglueckte ist Normalbetrieb. **Test:** noch keiner. Testbar waere: ein Zustand mit faelligem `wieder_aufnehmen_ab`, dessen Item nicht in pending liegt, muss nach einem Lauf dort liegen

Problem: Cron-Watchdog schlug Alarm: `tli:bookmark-triage` ohne Success-Marker. Der Job lief 04:00 los und wurde 04:15 vom Cron-Timeout abgeschossen (status=124), ohne ein einziges Ergebnis. Gestern hatte derselbe Job 12 Sekunden gebraucht. Betroffen ist derselbe Dienst, an dem heute frueh schon `deep-paraphrase-check` scheiterte -- die beiden Vorfaelle haben eine Ursache

Ursache: Der Hetzner-Inferenzdienst antwortet auf `/health` in 0,1 Sekunden mit "ok, 2 Modelle verfuegbar", waehrend **jeder** echte Inferenzaufruf nach 65 bis 80 Sekunden mit `upstream call failed: Connect: Too many open files (os error 24)` zurueckkommt. Beide freigegebenen Modelle betroffen. Der Fehler sitzt beim Anbieter: lokales ulimit 1.048.576, systemweit 4.672 offene Deskriptoren, langlaufende Node-Prozesse 22 bis 25. Im Skript griff deshalb keine Abbruchbedingung: Es prueft `service_status` (meldet "ok") und bricht nur bei `unreachable`/`auth_lost`/`model_gone` ab. Also arbeitete es zehn Batches à 80 Sekunden ab, bis der Cron es killte

Fix: `bookmark-triage.py` bricht jetzt nach drei Fehlschlaegen in Folge ab und meldet, statt in den Cron-Timeout zu laufen; ein erfolgreicher Batch setzt den Zaehler zurueck. Der Ausfall selbst ist extern und nicht behebbar. **Test:** nicht als Unittest sinnvoll -- der Fall braucht einen antwortenden, aber kaputten Fremddienst. Stattdessen als Regel: Ein Statusendpunkt beweist Erreichbarkeit, nicht Funktion; wer ihm allein vertraut, laeuft in Timeouts